Please do not use Python for tooling • Hacker News Board

Re: Please do not use Python for tooling

#81

Post by oliwarner » Thu, Aug 18, 2022, 11:50 AM UTC

> Whoa. The response to this blog posting seems to be extremely polarized.

Well, duuuuh.

I kinda get the argument. Nobody wants to spend time maintaining the tools they use to make other stuff, but the tools written in Python by Python developers are likely written that way to be useful, maintainable and in a language they're productive in. Immediate time is an important expense when you're writing tools.

You talk about sunk costs, but sinking time into becoming as proficient in (eg) Rust as Python seems ridiculous. Especially for smaller tools.

And why are we picking on Python? Javascript toolchains eat themselves every 18 months. Yeah Python versions upgrade but we're going to pretend that Node doesn't?

If you don't want a fight, don't pick one. Let developers use their own expertise and experience to decide what they use.

Re: Please do not use Python for tooling

#82

Post by dangerface » Thu, Aug 18, 2022, 3:08 PM UTC

bborud wrote: post #55

pwinnski wrote: post #20

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

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…

Tooling for embedded development? Please back in my day you just didn't get any tooling even the programer was left to the manufacture to make.

> It is kind of like demanding you understand and set the timing advance on your car's engine. Why on earth would you even want to know of it, much less fiddle with it?

Developers are not end users a technical understanding and capability is to be expected you aren't talking about the tooling for a pc you are talking about the tooling for a microcontroller.

A more accurate example would be the timing belt manufacture expects the car manufacture to provide their own tooling to put the timing belt on their engine, in the same way a pic manufacture expects you to provide your own tooling.

The end user is whoever buys the device you build with the pic in the same way that the end user of a timing belt is the person who buys the car not the manufacture that makes the car.

Re: Please do not use Python for tooling

#83

Post by bborud » Sat, Aug 20, 2022, 12:31 PM UTC

pwinnski wrote: post #79

bborud wrote: post #67

Earlier quoted context omitted.

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.

I wasn't criticizing Python as a language. I think you let your gut reaction run away with you a bit.

Re: Please do not use Python for tooling

#84

Post by bccdee » Fri, Aug 26, 2022, 1:34 AM UTC

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…

It sounds like your main issue is that you don't isolate your dependencies into virtual environments. That involves jumping through a couple hoops, sure (primarily just invoking `./venv/bin/activate` before you run the script), but for the most part it entirely resolves Python dependency problems.

Could Python's dependency management be less clunky? Absolutely. But ultimately, when it comes to the tools you mentioned, the vendor is the one responsible for not explaining proper Python dependency management in their documentation, or for not creating an ergonomic wrapper around it.