Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please do not use Python for tooling

borud.no

Post reply on HN
Print view View original

31–40 of 84 posts

Re: Please do not use Python for tooling

#32

Post by arunix »

acomjean wrote: post #18
rich_sasha wrote: post #7

Also don't use C or C++, i wasted so much time trying to compile stuff (no offence if you're a C dev). Also no Java please, how do I even install JVM on my system? Node and JavaScript, Ruby, Perl, Bash are out too of course. Bash sometimes works but what if I'm using a different shell?

Perl and Bash don't really change too much anymore. One of the upsides of the Perl 6 never happening is that Perl is relatively static. I think a lot of the issue is that these languages love to install .directories in your home directory where all your libraries live and it works seamlessly for you.. but no one else. We use python, perl and bash. Generally people who are more comfortable in one than the other just c…

Perl has yearly releases, but is generally good at backwards compatibility.

Re: Please do not use Python for tooling

#33

Post by bborud »

icedchai wrote: post #6
bborud wrote: post #5

Earlier quoted context omitted.

Could you provide an example of how you solve the problems with Zephyr or ESP-IDF using virtualenv?

It appears ESP-IDF can already be installed with a virtualenv: https://github.com/espressif/esp-idf/blob/master/tools/idf_t... Perhaps your problems are due to external dependencies (outside of Python)?

So how do you usually install ESP-IDF to ensure smooth sailing? I usually follow a (somewhat more terse) version of the instructions that the Espressif team have on their site. I put that in my blog a while back: https://borud.no/dev/2022/esp-idf-setup/. How should I modify this procedure to help avoid breakages in the future?

UPDATE: interestingly, I decided to check out and re-build an ESP-IDF project I haven't built since before the summer and now the build breaks because of wrong version dependencies.

My point was that why on earth should I have to manage all this stuff? I just want tools that work. This tooling doesn't really provide that. It provides me with more work.

Re: Please do not use Python for tooling

#34

Post by PaulHoule »

stuckinhell wrote: post #13

I just don't think python is a "fashionable" language. I think it's a nice utility or "glue" language. It can do almost anything (machine learning, web dev, etc) in a way perl can't, and so I don't see it disappearing like perl. As for the section on python being antisocial, It makes sense to me. Dependency management is a tough thing for python and javascript. However I would not switch to writing Rust or Go for too…

I rejected Python definitively in 1999 but got dragged back into Python programming a little less than 10 years ago because there was so much work.

It's easy to get into a place with Python is a nightmare. I worked at a place full of data scientists who couldn't get anything to work reliably because they installed things with

   pip --local
which contaminates all the python installations on your machine including Conda distributions. We also found many Pythons were misconfigured, for instance the defaults for

https://docs.python.org/3/using/cmdline.html#envvar-PYTHONIO...

depend on your Python and if they are set wrong and a bit of text gets ingested by the system and spit out by a 'print' your Python will crash. Since there are plenty of 'print'(s) that come in with packages you install with pip the answer 'don't print dirty text' isn't an answer.

On top of that there is the fact that pip's resolving algorithm is incorrect. It can solve simple cases but if you add enough packages it will break down.

Re: Please do not use Python for tooling

#35

Post by falcolas »

jrockway wrote: post #23

I 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…

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.

Re: Please do not use Python for tooling

#36

Post by polotics »

robsws wrote: post #25

The 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?

Re: Please do not use Python for tooling

#38

Post by schmuelio »

cassianoleal wrote: post #29
jrockway wrote: post #23

I 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…

> 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 this using id(). Python seems do do some fancy value stuff behind the scenes but you can see the variable changing its identifier in the following example:

    >>> a = "foo"
    >>> id(a)
    140105790230896
    >>> a = "foo"
    >>> id(a)
    140105790230896
    >>> a = "bar"
    >>> id(a)
    140105790230512
    >>> a = 1
    >>> id(a)
    140105793782000
    >>> a = "foo"
    >>> id(a)
    140105790230512
As for strong/weak, I think it's a bit more fluid because I can't seem to find a set definition that everyone agrees on. Some people consider weak typing to be when the language implicitly casts or converts types for you, which Python does not do:

    >>> a = "1"
    >>> a / 3
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: unsupported operand type(s) for /: 'str' and 'int'
    >>> type(a)
Except sometimes it kind of does? The divide operator converts int into float "implicitly" even when both inputs are int. So type conversion is happening behind the scenes (I don't know if you would class this as "implicit" type conversion, maybe it depends on where it happens?):

    >>> a = 10
    >>> type(a)
    
    >>> b = 1
    >>> type(b)
    
    >>> type(a/b)

Re: Please do not use Python for tooling

#39

Post by PurpleRamen »

falcolas wrote: post #35
jrockway wrote: post #23

I 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…

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.

Re: Please do not use Python for tooling

#40

Post by falcolas »

invalidname wrote: post #21
j0hnyl wrote: post #9

"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.

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.
Post reply on HN