One word. Virtualenv.
They are a solution, but not a good one for this problem. Are Virtualenvs portable today? And are they used that way? And I don't mean the script/recipe for creating the virtualenv.
Please do not use Python for tooling
41–50 of 84 posts
Re: Please do not use Python for tooling
#42Earlier quoted context omitted.
Containers work particularly well for python environments. You can get them working locally, but it's easiest when the developers stick with the standard library. Needless to say, virtually nobody does.
But are containers portable? Can you take them, send them per mail or put on a USB-stick? And I'm not talking about the recipe for creating them, but the actual container itself.
Yes.
The actual image is a tar file, and container runtimes include commands for both exporting and importing. Exceptionally portable. More portable than JAR files and Go binaries, at least.
Re: Please do not use Python for tooling
#43"In a pinch, even Java provides a better alternative as you have the ability to build all-in-one-jar files that contain all the dependencies. Not fashionable, but objectively a far less brittle option." Really? In a pinch, use a language that's 90% boilerplate and relies on a mastery of the IDE? It's hard to take this seriously.
It’s hard to take your comment seriously either, based on such a hand-wavy and false description of Java. Like, other than writing implements instead of <: or whatnot, how on earth does Java have any serious amount of boilerplate?
Re: Please do not use Python for tooling
#44The article is kind of hyperbolic, but I feel like it echoes how I am beginning to feel about Python. Just last week, I spent a whole afternoon getting a particular repository of Python code running on my laptop, even with the help of virtualenv and pyenv. requirements.txt doesn't tell me which version of Python the code was developed with, and several libraries are only available on certain versions, so I have to pl…
you write: "requirements.txt doesn't tell me which version of Python the code was developed with". Do you expect to have less pain with any othe rlanguage with this situation?
“Here is a binary” sounds a lot less painful.
Re: Please do not use Python for tooling
#45Earlier quoted context omitted.
You don't like people being hard on Python fine. Don't do the same for Java. Modern Java doesn't have nearly as much boilerplate and is nearly as concise as python. Relying on IDE Python can be great and so can Java. Different strokes. Different use cases.
Modern java relies on Lombak (code generation) and DI frameworks (seriously, fuck DI) to avoid boilerplate. The base language has just as much of it as it always has. And, as I just found out this morning, DI frameworks blow up at runtime despite successful compilation and runs through unit testing.
> The base language has just as much of it as it always has
Which is roughly equal to that of C, C++, and many other languages, being a tiny constant percentage larger than equivalent code in some “modern” language.
Re: Please do not use Python for tooling
#46Earlier quoted context omitted.
You don't like people being hard on Python fine. Don't do the same for Java. Modern Java doesn't have nearly as much boilerplate and is nearly as concise as python. Relying on IDE Python can be great and so can Java. Different strokes. Different use cases.
I don't mind people being hard on Python, but the idea of Java over Python "in a pinch" is lost on me, but what do I know...
As a consumer of a program, you don't really care about what language it was written in. But you do care about to what degree you have to involve yourself in the process of getting the software to run.
Java was mentioned because it offers a way to package all dependencies in a single file. From a user perspective this is preferable to "here is a program, now you have to gather all the pieces to make it run without breaking stuff". Whether one loves/hates Java doesn't really enter into it.
The language itself is somewhat irrelevant for the discussion - the way in which software is distributed and installed is the real point. Python isn't particularly nice for tooling since it offloads a lot of work on the consumer. You download a Python program, then you have to care about how you should run it, which language version it is, make sure the dependencies are downloaded etc. And even if you have gotten it to run today, tomorrow it may not work. For myriad reasons.
Re: Please do not use Python for tooling
#47I don't think the type system particularly matters. You can make something work without assigning a type like "int" to variables. Python doesn't let you do things like "foo" + 3 (while Node is happy to), so even though you're not naming your types, the types are still static. One unexpected downside of static languages are dealing with web services written in dynamic languages. As an example, I was writing a Slack ap…
> the types are still static.
Python is a dynamically, but strongly typed language. JS is dynamic, but weakly typed. Java would be an example of a statically and strongly typed language, and C may be a statically and weakly typed language, but I’m not sure this latter is an apt description (you can cast anything in C and it may work, while this will fail in Java if the types are not compatible)
Re: Please do not use Python for tooling
#48What a bizarre take. It seems to boil down to: "Tooling should be compiled so it doesn't involve dependencies." If we lived in a world in which most tooling (currently written as python scripts) were actually compiled, we'd be seeing better-reasoned essays begging us to write tooling as easily-editable scripts, rather than closed-off executables. I have had scripts that I needed to edit just slightly almost every tim…
It doesn't need to be compiled. The writer just says that a tool should be future-proof. And future does not mean 18 months, but 10 or 20 years. Python makes this rather hard, and has no real culture around this.
And it's true, python-code has a relative high maintenance-cost and deployment is still one of the dominating complains. But I would say this is just the cost that comes with the low entry and fast development.
There are other ways than compiling stuff, some are used today, some others are developing slowly. But at the moment python is really not at the point where long term-availability is a big target.
Re: Please do not use Python for tooling
#49Earlier quoted context omitted.
> even though you're not naming your types, the types are still static. Python is strongly typed, but definitely not statically. >>> a = "foo" >>> type(a) >>> a = 3 >>> type(a) The variable `a` has different types at different parts of the program. That's not static.
Your example doesn't show static typing (declaration/re-declaration is the same syntax as assignment in Python), but I think OP was thinking of Strong/Weak? Python is Dynamically typed because: >>> a = "foo" >>> a / 3 Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for /: 'str' and 'int' This isn't a compile error. Edit: Also for the re-declaration thing, you can see thi…
Thanks for the correction and the comprehensive examples!
Re: Please do not use Python for tooling
#50How do you feel about containers, OP?
As in building containers to run tooling? I've gone down that route quite a few times and it usually isn't ... terrible. I've had some issues with access to USB and hardware from containers, but I can't remember the details anymore (I ended up ditching the project because of alternatives that were easier to work with).
One challenge is that when you work on a team and you know there will be people who have to maintain this stuff further down the road, you have to both ensure that they can make use of the technology (are allowed to by their employer) and that it is documented. I've worked with companies that won't allow Docker for instance (for reasons I was never made aware of).
(A lot of people seem to have gotten really upset about this posting. Most of the comments seem to indicate that a lot of people didn't actually read it and/or understand the context. It wasn't a language shitpost. It was a plea for people to please stop making tooling that just creates a lot of work for other people).