That said, copying is in this case the end result of distinct different methods. In the stackoverflow answer, the only redundant way to copy is the .copy method list has. If I understand right it is just a convenient method in order so new programmers don't need to import the copy module.
list() is a common way to create a new list, and the constructor can take a initial sequence. Lists are sequences, so list can take a list, but that is just a side effect.
Slicing is very useful for taking the first or last objects of a list. if you take all the first and all the last objects, you get a copy. Its not the primary function of slicing, but a useful side effect.
The copy module is a lower level interface to work with python objects. As any other lower level interface it mostly used in exception cases when you really want a "deep copy". I have used that trick once in my whole programming career, and it was to work around a restriction in a third-party module for a corner case which they clearly didn't consider.
This, above many other things, keeps me coming back to Python year after year.
If it comes to you naturally, fine, just realise that people are different and have different skills, memorization techniques and care about different things.
Some programmers are like you (a tiny minority afaik) and can read a dry spec or a book and remember all the intricacies and gotchas. It takes a certain type of mind to do that. And I would note that none of the people I knew who could do that were particularly good programmers.
Others, most as far as I've seen in my more than a decade career, learn by making, experimenting and adapting examples.
This is made worse now in some ways because back in the day many editors used to have fantastically well written and edited help, and that has generally disappeared.
Press F1 on a type or function and you'd get reams of well written examples and explanations.
Now most programming languages don't, the documentation is sparse and they simply rely on Stack Overflow and Google to provide all the examples for them.
However, that means that old ways of writing things can stick around as often no-one edits a SO answer to correct it.
You mean you haven't heard of books, or can't read, or can't be bothered? Presumably none of these so what are you saying?
> just realise that people are different and have different skills, memorization techniques
Fine, I agree totally, use those! But here's what the original poster said "generally accepted best way to perform this operation that leverages the standard library and there is seemingly no other way to discover what that is". If you can find the answer on SO, that's fine - you have your answer! But that's not what he said. He said there's no way of finding it. I said it's in books, you say it's on SO, so there clearly is.
> Some programmers are like you and can read a dry spec or a book and remember all the intricacies and gotchas
Which I can't and don't. Please re-read my penultimate sentence where I said it's ok not to, nor was there need to. Kind of twice in fact ("You're there to deliver results correctly to the business, not deliver idiomatically perfect code." -and- "There's NO shame in not crawling into the furthest, darkest corners of a language.")
> And I would note that none of the people I knew who could do that were particularly good programmers
Oh noes, I haz been trolled :)
> Now most programming languages don't,
No language I've ever used ships with a tutorial (oh wait, delphi's did. Rather crap but it was there). Python's online docs are ok (not great, ok). So pick a book. I already recommended one. Reading is the same whether it comes from paper or phosphor. Just don't complain it needs work. It does. Sorry.
From experience: not knowing how your tools work is a recipe for vastly increasing your workload. Reading a book is a boring, tedious shag but will give you the greatest savings of time overall.
> learn by making, experimenting and adapting examples
Yup, that too. Books AND that. You're quite right. I should not have overlooked that.
But the original poster claimed info was just so hard to get and I said it wasn't.
Horses for courses, ok. In reality it's books + SO + lots of online info + your local expert (there's usually one at least, though expertise is relative) + transferable skills from other languages.
All I'm saying is you need that info, and it's there, one way or another. There's so much info now out there compared to when I started programming. It's there, use it.
Similarly, taking a dance class won't make you a dancer, but it helps.
Like for this specific example:
https://stackoverflow.com/questions/2612802/how-to-clone-or-...
Knowing the right thing to do requires you be informed about the history of Python language design. Like you could just read the documentation and see that lists have a copy method but it doesn't give you a good grasp of what the alternatives are and why you might choose them. And prior to Python 3.3 you're expected to know that the best practice way to do this is to leverage an edge case in the slicing syntax or the list function. Doesn't matter if you're the best computer scientist in the world, sifting through the massive corpous of documentation and historical knowledge required to write good Python is nigh impossible unless you're willing to dedicate yourself Python.
This is something that languages need to tackle because the gap between doing a thing and doing that same thing in a way that follows language conventions and best practices is too damn high.