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

71–80 of 84 posts

Re: Please do not use Python for tooling

#71

Post by rascul »

polotics wrote: post #36
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?

Rust has a way to specify the minimum rustc version.

https://doc.rust-lang.org/cargo/reference/manifest.html#the-...

Re: Please do not use Python for tooling

#72

Post by invalidname »

falcolas wrote: post #69
invalidname wrote: post #52

Earlier quoted context omitted.

Nope. Records, lambdas, var, multiline strings, switch pattern matching, improved instanceof, etc. I suggest reading up on Java 18 and some of the upcoming features.

Those are improvements, no doubt, but they don't even begin to touch the quantity of boilerplate removed by Lombak.

Records do. You need Lombok for very specific things. JPA, etc. If you use JPA then the benefits and capabilities far outweigh any boilerplate or dynamic runtime overhead.

Re: Please do not use Python for tooling

#73

Post by michaelanckaert »

actuallyalys wrote: post #19

Python is definitely not as easy to distribute as it should be by 2022, but I'm not ready to throw it out yet. I think tooling authors need to look into packaging. Python actually has something similar to JARs, zipapps [0], although I have yet to see them in the wild. PyInstaller is a more well-known option. [0]: https://docs.python.org/3/library/zipapp.html#creating-stand...

I never knew about zip apps! After using Python for over a u years I still discover new stuff!

Re: Please do not use Python for tooling

#74

Post by bborud »

palotasb wrote: post #60
bborud wrote: post #55

Earlier quoted context omitted.

The place where I run into Python is mostly while doing embedded development as the tooling for platforms like Zephyr and ESP-IDF. And they are notoriously brittle. Which has a high cost in terms of lost productivity. So we aren't talking about scripts I maintain, but scripts that are part of the tooling for platforms I use. The point is that it doesn't matter what a theoretical developer could do to lower the "cost…

I'm not sure about the problem of brittleness caused by buggy scripts you must rely on -- you'd get that in any language. But if the brittleness is caused by slightly different dependencies being installed for each developer or CI machine, I also recommend creating development environment setup and activation scripts that create a reproducible development environment (based on a requirements.txt generated via pip fre…

The end user of the software could do all that, yes. Or the tooling could have been done in a manner that didn't make it so brittle the user has to come up with mitigation strategies to keep things running.

Re: Please do not use Python for tooling

#75

Post by polotics »

rascul wrote: post #71
polotics wrote: post #36

Earlier quoted context omitted.

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?

Rust has a way to specify the minimum rustc version. https://doc.rust-lang.org/cargo/reference/manifest.html#the-...

Rust is so cool. In python's requirements.txt you can put something like:

tensorflow >=1.12,!=2.1.*

Re: Please do not use Python for tooling

#76

Post by robsws »

polotics wrote: post #36
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?

I'm not saying other languages don't have the same problems, but this just hasn't been as much of an issue in my experience when working with other languages.

C# for example - I had some compatibility issues between versions 2 and 3.1 of .NET Core, but at least the .csproj tells me what version it's supposed to be built with, and the LangVersion property indicates the version of C#.

Re: Please do not use Python for tooling

#77

Post by bborud »

PaulHoule wrote: post #61
bborud wrote: post #33

Earlier quoted context omitted.

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

It's a general story that companies like Espressif couldn't care less about developer experience. Part of why Arduino is a success story is that their dev tools, limited as they are, are easy to get going. Microchip publishes free tools to work with Atmel parts and they have a better feature set but are a hassle to get up and running. I think there's an expectation that top management decides which board gets used an…

What Arduino did right was to understand that you have to make sure the tools run regardless of what is installed on the target machine. You make a software package that has everything it needs to do the job without external dependencies.

Now look at the discussion here. A surprising number of people actually expect users to have to understand the runtime requirements and environment of the tooling and seem to think it is the user's job to learn Python and manage this.

Not a lot of people here "get it". And oh boy do people get offended if you suggest that one may have something to learn from the kind of thinking that went into Arduino.

Re: Please do not use Python for tooling

#78

Post by bborud »

bb88 wrote: post #63
bborud wrote: post #55

Earlier quoted context omitted.

The place where I run into Python is mostly while doing embedded development as the tooling for platforms like Zephyr and ESP-IDF. And they are notoriously brittle. Which has a high cost in terms of lost productivity. So we aren't talking about scripts I maintain, but scripts that are part of the tooling for platforms I use. The point is that it doesn't matter what a theoretical developer could do to lower the "cost…

As a professional python dev, I understand your pain. It took me a while to sort out the pyenv/virtualenv/conda stuff myself. Could python be better in this regard? Yes, absolutely. I wrote a comment a while back to help out someone else with python packaging. Once you get your mind around it, it's not too bad frankly. https://news.ycombinator.com/item?id=32122191

The perspective I'm trying to shine a light on is what it is like to be the consumer of tooling written in Python - not the author.

I was a bit unclear in the title (which is what most people seem to have read, and then skimmed the blog posting), but the tooling I'm talking about is things like the `west` tool for Zephyr or the `idf.py` tool for ESP-IDF. Tools that are centrally maintained and distributed. Not the ad-hoc tools people use to do various chores in their codebases.

Both of the tools mentioned are notorious for being extremely brittle. Actually, as we speak, I'm trying to figure out why a project that worked before I left on vacation, and which has been untouched for several weeks, now suddenly doesn't build (because the tooling doesn't run). This is actually par for the course. You have to expect things to break for no obvious reason. My guess? I probably updated some other piece of software and it upgraded a common dependency.

I spend about 10-20% of my time dealing with this sort of nonsense.

Re: Please do not use Python for tooling

#79

Post by pwinnski »

bborud wrote: post #67
pwinnski wrote: post #65

Earlier quoted context omitted.

You took a very specific complaint about toolkits in the embedded systems space and generalized it to an expanded argument about any and all tooling, much of which have requirements that run directly counter to yours. So yes, I don't think you communicated your point well. An essay about the brittleness of current embedded systems toolkits which suggested that much of the brittleness could be due to the use of Python…

Actually, I haven't seen anyone make a compelling argument that counters any of the things I point out. I've mostly seen people either suggest workarounds or being upset that someone would suggest Python isn't the best thing since sliced bread. You keep harping on about the last point. Which makes me think that you really felt that it hit home with you.

> You keep harping on about the last point. Which makes me think that you really felt that it hit home with you.

Yeah... your communication skill is pretty bad on both ends, it turns out: out and in.

I'm a Go developer who has used Python for scripting, and for teaching my daughter about programming. I don't care to defend Python as a language, but I do care about clear communication, which you continue to lack.

Re: Please do not use Python for tooling

#80

Post by bb88 »

bborud wrote: post #78
bb88 wrote: post #63

Earlier quoted context omitted.

As a professional python dev, I understand your pain. It took me a while to sort out the pyenv/virtualenv/conda stuff myself. Could python be better in this regard? Yes, absolutely. I wrote a comment a while back to help out someone else with python packaging. Once you get your mind around it, it's not too bad frankly. https://news.ycombinator.com/item?id=32122191

The perspective I'm trying to shine a light on is what it is like to be the consumer of tooling written in Python - not the author. I was a bit unclear in the title (which is what most people seem to have read, and then skimmed the blog posting), but the tooling I'm talking about is things like the `west` tool for Zephyr or the `idf.py` tool for ESP-IDF. Tools that are centrally maintained and distributed. Not the ad…

If you have issues like that, definitely look into virtualenvs and requirements.txt. It's meant to isolate python environments from breaking like that.
Post reply on HN