3 ms·
Mostly you should start by reading what's shipped with core. After that, look at larger projects with lots of committers, as they often end up getting "polished
by 0xbadcafebee 3y ago
Mostly you should start by reading what's shipped with core. After that, look at larger projects with lots of committers, as they often end up getting "polished" down to something that's sort of generically useful without being too quirky or too simple, and the architecture tends to be more functional.
Avoid anything developed/maintained by one corporation. In general, their organizational hierarchy leads to bad patterns and resists useful changes that don't conform to the goals and patterns of the business or engineering leads. Grassroots OSS projects aren't always better, but they're less likely to have a monoculture and perverse incentives.
- martinky24 3y agoPython is an example of a language where, in general, the standard library probably isn't the best thing to read if you want to learn to write downstream Python applications/libraries. It can be terse, and not follow "modern" best practices in places (it was written at a time with different "best practices", but the code works so no need to change it). There are some exceptions... I'd say the `statistics` module is one [1], the `collections` module might be another [2]. But in general, it's probably not the best place to start. If you stumble upon the `multiprocessing` library source code as inspiration for "good Python code"... you're going to be in for a bad time and your future collaborators will not be happy. [1]: https://github.com/python/cpython/blob/3.12/Lib/statistics.py https://github.com/python/cpython/blob/3.12/Lib/statistics.p... [2]: https://github.com/python/cpython/blob/3.12/Lib/collections/__init__.py https://github.com/python/cpython/blob/3.12/Lib/collections/...