Yes there is, it's called reading a goddamn book.
> Knowing the right thing to do requires you be informed about the history of Python language design
Bullshit, it requires you knowing the language. Perhaps by reading a book. Knowing the history is of little value.
> 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
Total crap, just read a decent book. About 3 years ago I learnt python from 'Learning Python' by Mark lutz (5th ed) for a new job. I spent 3 weeks going through ~1000 pages and reading stuff on the web. I amazed a guy there when he found out I'd just learnt python, ie. wasn't a veteran at it. He'd used it for years.
Difficult, right, putting in all that work? Well that's called doing your job as a programmer. Happens I'm about to return there so I'm brushing up on it by going through it again.
I would have some sympathy with your position if you hadn't made it out to be such a terrible task. It's not. It's called doing your due diligence as a programmer.
And I have real sympathy with the guy who posed the question you gave from StackOverflow, but the key is once you've learnt about object references, say in delphi, you carry across that understanding to scala/java/python/everything else.
90% of stuff will carry between programming languages. Once you learn OO, functional, procedural, logical langs you recognise and underlying commonality. And most of all, programming is not about a specific language but problem solving and general principles, so getting hung up on a particular lang is missing the point.
My first year out at university I worked at an engineering company and got the best advice ever: first thing to do is pick up the docs and start reading. It's stood me well ever since.
If there are too many options (ie. your comment on slicing vs other stuff), yes, I see but the answer's simple: pick one way and stick to it; either slicing syntax or list methods. You're there to deliver results correctly to the business, not deliver idiomatically perfect code. There's NO shame in not crawling into the furthest, darkest corners of a language.
Excuse the rant. It'll come with experience, just trust yourself and ask questions to any experts you can find.