Look through the stack you’re familiar with. For me that means nginx, uwsgi, flask, sqlalchemy, alembic - but I’ll look at anything I have a question about.
My trick is to dig in when something doesn’t work the way I expect. Or someone says “I don’t think there’s a way to do X with blah”. My immediate reaction is to clone the code and take a look. I have a “tools” folder on my local machine that contains many of the tools / libraries is use.
Orientation is easier than you expect. The easiest scenarios are around “why did I get that error” situations. Grep for the error and away you go. But having a question to answer will definitely give you a direction to investigate.
I agree about having an error to investigate or a question to answer. Some of the python libraries with great code I'd recommend reading are Flask and Werkzueg. Both have very clean interfaces and excellent documentation. Sqlalchemy is somewhere in the middle. As an ORM it has a high minimum level of complexity. But the codebase is still reasonably well organized. Looking for an answer to something like "how does it emit a JOIN" may be a lot harder to answer than you expect though.
For packages to avoid, stay away from Celery. It's just... icky.
Yup, sqla is super meta and, thus, complicated (just due to the problem space). Better is alembic / alembicutils where you can dig into the autogenerate system they’re layering over sqla.
Weirdly enough, I enjoy digging through C and Java libs more, mostly because they’re more unfamiliar to me. I’d spend more time in Postgres / fontforge / mupdf / pdfbox / nginx / uwsgi on the whole.
I think the recommendation to study Flask's code base is an echo from years ago, when it was considered a micro/toy framework. I used to recommend it too. As a more seasoned programmer, I don't anymore. Having used and studied the framework, I've seen some of the limitations that directly stem from some of its design choices. Today, I think it tried to be needlessly clever sometimes. Some of those choices, that seemed fun and clever back in the days, did not age well. As time went and people started pushing the framework, some artefacts required hackish workarounds. And those kept cumulating. To such an extent that the codebase now has a bunch of flags that control it's contingent behavior; ifs and buts that make the whole thing harder to reason about. You'll still learn lots of clever Python tricks, but I wouldn't put it in the "clean and clear" category.
My trick is to dig in when something doesn’t work the way I expect. Or someone says “I don’t think there’s a way to do X with blah”. My immediate reaction is to clone the code and take a look. I have a “tools” folder on my local machine that contains many of the tools / libraries is use.
Orientation is easier than you expect. The easiest scenarios are around “why did I get that error” situations. Grep for the error and away you go. But having a question to answer will definitely give you a direction to investigate.