Python at Scale: Strict Modules
instagram-engineering.com
Python at Scale: Strict Modules
1–10 of 259 posts
Re: Python at Scale: Strict Modules
#2I love the idea, but it feels like just an idea at this point. I'd rather read about them releasing their 'compile-time' analyzer and revealing their measurements for how much startup time it saves.
In our codebase, we have pretty strict developer-enforced rules about not doing I/O at the module level, usually through the use of simple "Lazy" wrappers for module-level objects. I'd be curious to know what other approaches people have taken with Python here.
Re: Python at Scale: Strict Modules
#3It's very important to think about objects lifecycle management.
It's also important to... use pytest fixtures instead of arbitrarily patching around in tests.
Re: Python at Scale: Strict Modules
#4I love the idea, but it feels like just an idea at this point. I'd rather read about them releasing their 'compile-time' analyzer and revealing their measurements for how much startup time it saves. In our codebase, we have pretty strict developer-enforced rules about not doing I/O at the module level, usually through the use of simple "Lazy" wrappers for module-level objects. I'd be curious to know what other approa…
It is an interesting approach, though I feel like this could introduce some nasty unintended consequences given how dynamic and introspective Python can be (admittedly I haven't studied this particular implementation).
I always treated this a bit like single underscore private functions/methods, i.e., follow a convention that produces code that's easy to reason about, even if it's not strictly enforced by the language/compiler. So in practice this equates to separating out modules that mutate global state, and placing the majority of logic in "strict" modules that only declare a bunch of "pure" classes/routines. So the "non strict" code is really just a thin layer of wiring gluing everything together. For instance my Celery task files tend to be very thin.
Re: Python at Scale: Strict Modules
#5It still blows my mind that people don't use strongly typed languages in the first place and spare themselves from all this future pain.
My guess (based on my experiences) is that companies wind up in this position from having inexperienced people building early versions of products instead of hiring experienced engineers (who are usually more expensive).
Re: Python at Scale: Strict Modules
#6This article is among the best argument for using a typed language I’ve yet seen.
Re: Python at Scale: Strict Modules
#7It still blows my mind that people don't use strongly typed languages in the first place and spare themselves from all this future pain. My guess (based on my experiences) is that companies wind up in this position from having inexperienced people building early versions of products instead of hiring experienced engineers (who are usually more expensive).
Python is strongly typed, just not static.
Re: Python at Scale: Strict Modules
#8This article is among the best argument for using a typed language I’ve yet seen.
This has nothing to do with types. It's more about static guarantees the language gives about module import behavior.
Re: Python at Scale: Strict Modules
#9It still blows my mind that people don't use strongly typed languages in the first place and spare themselves from all this future pain. My guess (based on my experiences) is that companies wind up in this position from having inexperienced people building early versions of products instead of hiring experienced engineers (who are usually more expensive).
Python is strongly typed, just not static.
Python uses duck typing: https://en.wikipedia.org/wiki/Duck_typing
I would categorize it as a subset of dynamic typing, and that's what Wikipedia says too.
Re: Python at Scale: Strict Modules
#10It still blows my mind that people don't use strongly typed languages in the first place and spare themselves from all this future pain. My guess (based on my experiences) is that companies wind up in this position from having inexperienced people building early versions of products instead of hiring experienced engineers (who are usually more expensive).
It's a constant struggle against the current. Dynamically-typed
languages are often “good enough for the time being”. I have the same
issue explaining to our C/C++/Obj-C team why they should use static
(Clang-Tidy, Infer, PVS-Studo) and dynamic (ASan, MSan, UBSan) analysis
tools. They just keep giving me basically the same response of “I am
a good programmer, and my code is good, and shame on you for even daring
to think that a mere machine could find bugs in my code!”. I don't know
what kind of status anxiety causes it. It also makes me think about
what kind of other I am missing because of the was I keep thinking
that I do that thing well-enough myself.