Please do not use Python for tooling
I don&#x27;t think the type system particularly matters.  You can make something work without assigning a type like &quot;int&quot; to variables.  Python doesn&#x27;t let you do things like &quot;foo&quot; + 3 (while Node is happy to), so even though you&#x27;re not naming your types, the types are still static.<p>One unexpected downside of static languages are dealing with web services written in dynamic languages.  As an example, I was writing a Slack app in Go a couple years ago.  Some response gets unmarshalled into an easy-to-use struct, but contrary to the documentation, the server has no interest in returning data that can always be unmarshaled into that struct.  Sometimes instead of a list of 1 element, the value will just be that one element.  There is no type &quot;[]Foo|Foo&quot; in Go, so now you have to write a custom unmarshaling function (or say &quot;fuck it all!&quot; and use map[string]any, at which point you&#x27;re just writing Javascript).  This doesn&#x27;t cause problems for people using Python or Javascript because neither of those care what&#x27;s in a dictionary, but statically typed languages do, and you&#x27;ll have to write extra code to work around that.<p>I agree that it&#x27;s annoying to require the users and tool author to have the same runtime and packages installed, though.  Python is an incomprehensibly large can of worms here.  A python package&#x27;s dependencies are architecture&#x2F;platform dependent.  To install C packages, you need the exact same C compiler that was used to build Python.  Some popular packages have an indirect dependency on a Fortran compiler.  It&#x27;s a pretty big nightmare.  You could bundle the runtime with the application like Go does, but the runtime is pretty big and the language is too dynamic to remove the parts you aren&#x27;t actually going to use in advance, so it&#x27;s not as easy as a sell.<p>An option there is that if you&#x27;re using Python for internal tooling, you bless a particular version once a year, install it on every workstation, and say &quot;sorry, you can&#x27;t use a different version of Python&quot;.  That will alleviate a lot of the author&#x27;s problems, but obviously it&#x27;s exceedingly politically unpopular.<p>Anyway, there probably isn&#x27;t an objective truth here, just personal and organizational preferences here.  I agree with the author in that whenever I write some tooling in Python, I regret it almost immediately.  But it&#x27;s working for people.