Your first step for that identification should be to list your priorities for the end result. Readability? Robustness? Speed? Compactness? Reusability? Extensibility? Once you know by what metrics you want your code to be "good", you can start to examine where your code falls short.
The other key thing is to be unafraid to write bad code. It's hard to know when or why something's bad until you've held it in your hands, fiddled with it, given it a good swing. From there you can refine it by whatever metrics you've prioritized (per above).
Counterintuitively, being afraid to write bad code actually leads to bad code.
Good code is not a state, it's a process.
For example, science tries to be more correct by seeking out the places where it is wrong, but so many people who would be afraid to be shown to be wrong and will pretend they aren't even when they are.
Or for another example, evolution makes things robust by intentionally eating shit and dying. Yet humans use this as an insult! So you have a beautiful idea that outperforms what we think is clever when given long enough, but look how badly our culture evaluates it!
The cleverest approaches are actually intentionally stupid: game theoretic reasoning in complex situations under imperfect information calculates the counterfactual regret of the worst outcomes it could experience relative to what it actually did. Collecting the right experiences is actually what lets you get to the better experiences.
That’s Django speak for “do not mess with these - they are not intended for the developer to use in any way.”
I like how Django’s documentation is so complete, that leaving something out feels like it’s a protected class.
The monkey patching worked great.
I ended up going to a front end team working in Angular. Now I miss it.
Rust to me is a better python, can make python modules (py03 ftw) and the 30x speed up you get from using it is great... Oh yeah there is a borrow checker but it is not that bad once you grok it.
Edit: autocompelete!!!!!!
Next google "idiomatic python." Idiom is the software word for the "right" way to do something.
After linters and idioms, code will probably look pythonic. Next is overall structure, which IMHO, python is not super opinionated on.
What becomes more useful to understand are the different software paradigms: procedural, functional, and object oriented.
Once you understand paradigms a bit, it's worth understanding object oriented in more detail. Misko Hevery has a lot of great things to say on that.
At this point, you should be able to write extremely boring python. Nothing is better than extremely boring code.
After that, watching videos, reading books, reading code, and writing code is the way.
Learning google's Bazel is probably also important, since any sufficiently large python project will crumble under its own complexity without Bazel or a system like it.
I would also recommend trying to 'think' in the language. Don't just try to push a solution into the language. Dig deep and see if there is something specific that makes the most sense to use.
Overall, I wouldn't try to push away your style entirely. I don't think you truly can. I would say the best bet is try to be a great engineer, with strong baseline principles which you then apply in the best way for each environment. Every decision is a tradeoff and many of the big schisms in tech come down to taste. Actively work to learn new ways of doing things. Work to understand other's code longer than you think you should.
Effective Python is a great book which aims to teach people who already know the language how to use it well.
Every now and then read Zen of Python and try to understand it. Tim Peters somehow managed to fit enormous amount of wisdom in it.
I believe this was a good one back in my day. https://github.com/psf/requests
Then set up some compete workers that read in jobs from a RabbitMQ queue. Have the Rest service add jobs to the queue and get back the results.
Also you can just read the official Python tutorial for learning stuff like with contextmanager.
Once I understood fstrings, list/dict/set comprehension, and tuple unpacking, it became much easier to read and learn from others' python code.
Review code and ask lots of questions, you wont learn anything if you don't ask why?
Combined with a good book (eg learn python the hard way) it’s an approach that worked for me.
