Hacker News Reader

Comment by scosman | Hacker News Reader

Being new to python, the astral stuff is such a relief.

I don’t think experienced python folks realize how much the flexible tooling slows people down, and creates friction for adopters. Setting up my project I tried 3 environment managers, 2 type checkers, 3 formatters/linters, 3 packagers/dependancy/project managers.

I know this is kinda the n+1 issue where astral is just adding another. But it feels like a complete and well designed stack, not a box of parts encouraging me to build my own. Reminds me a bit of go tooling.

I am a convert. I’ll happily jump on their type checker and packager when ready.

View on HN

>Setting up my project I tried 3 environment managers, 2 type checkers, 3 formatters/linters, 3 packagers/dependancy/project managers.

I've been using Python for right about 20 years now. I've been through various prior iterations of the "standard" packaging tools. But I've never found myself wanting a type checker, formatter or linter; and aside from a brief period with Poetry (in which I used barely any of its functionality), I've had no interest in dependency management tools, either. What I have found myself wanting is fixes for the problems in Pip.

Different people work on different kinds of projects, and approach the language differently, and have radically different needs as a result.

> I've never found myself wanting a type checker

Do you still write type hints, but not check them? Or just use dynamic typing as in Python 2?

Actually, I guess the first case is really type-hints-as-comments, so isn't substantially different from the second.

> I've been using Python for right about 20 years now

Either way, I've found it quite common among long-time Python users to stick with Python's traditional dynamic typing, whereas newcomers to the language tend to really dislike it in favour of strict static typing. (One exception is GvR himself, who seems to be very pro-type-checking.)

As the second group continue to add increasingly complex typing features to the language, I wonder if Python is becoming less desirable for those in the first group.

>Do you still write type hints, but not check them? Or just use dynamic typing

I occasionally write them as a form of documentation - when it would be more concise than explaining in prose.

There is nothing specifically 2.x-style about making use of dynamic typing - it's a core property of the language. While 3.0 introduced the annotation feature, it wasn't even specifically intended for typing (https://peps.python.org/pep-3107/) and standard library support wasn't added until 3.5 (https://docs.python.org/3/library/typing.html).

>As the second group continue to add increasingly complex typing features to the language, I wonder if Python is becoming less desirable for those in the first group.

Some new changes have been missteps, in my view. There's still nobody forcing my hand when it comes to typing, really; I just shake my head when I see people trying to make it do things it really wasn't designed for. On the other hand, there are definitely things I'd love to see improved about the language.

What new changes do you think have been missteps?

Mmh - that's difficult. I should dedicate a blog article to that topic. Probably can't get to it until next month, though.

Working on a team in a larger python application, type checkers and linters are such a time saver. It's so nice not to think about how I'd like to format my code any longer. We've made some tweaks to our ruff rules to suit the team's opinion, and now even when I don't _love_ the way it formats a particular part of code, I just move on and get something productive done instead.

And type checking is so great for both preventing bugs (which it does all the time) and self-documenting code. Can't recommend them enough.

In my organisation, some co-workers used to write def func(*args,**kwargs) all the time. That was so tiring to look for what you should put as argument. Type checking is mandatory for well organized large project.*

It takes out so much frustration too. No more nitpicking about style/... in merge requests, the pre-commit hook will fix it and CI will catch it if you don't.

The more of this you can automate, the more you get to spend on "real work".

Yes yes yes.

I have my own formatting preferences, but my desire to not have to think about them or go to meetings debating them is much much greater.

I’ve been using it for around the same time, and never cared much about formatters. Linting is useful but wouldn’t call it essential. But type checking is a non negotiable on any project I lead. It’s not perfect by any means, but beats having to crawl my way through a call stack trying to figure out what the hell a function is expected to take and why it’s getting a None instead.

I have yet to find a single drawback of adopting mypy (or similars) that isn’t completely eclipsed by the benefits.

>I've never found myself wanting a type checker, formatter or linter;

I guess that makes one of us.

https://en.wikipedia.org/wiki/The_Fox_and_the_Grapes

The point he is making is that a lot of stuff that you are told you need. You actually don't. Especially if you are working by yourself or in a very small team.

Getting stuff working is much more important. I'd rather people concentrate on stuff like CI, Unit Tests and Deployments.

I've seen plenty of projects where people had that attitude except the thing they saw as time-wasting was the CI and Unit Tests.

Those projects weren't even dumpster fires.

You can, genuinely, do without all of this stuff — but they're just helpful tools, not silver bullets or the only way to do things, but helpful.

Never said it was a silver bullet. I said I would rather people concentrate on more important things than configuring a linter. Half the time this stuff gives you weird errors that don't make a lot of sense (especially with JavaScript/TypeScript), sometimes you are literally making the compiler warning go away because there is literally nothing wrong with the code.

I do use eslint/prettier btw, but other collegues can never seem to get this working so I've just given up on it and then fix the linter issues whenever I come across them.

> Never said it was a silver bullet.

Between this and your other comment*, you seem to be simultaneously expecting me to be more and also less literal in how I read your comments.

* https://news.ycombinator.com/item?id=42786325

I expect you to be able to use your brain to distinguish obvious hyperbole (it was absolutely obvious) with a matter of fact statement.

I am starting to suspect that this playing dumb is entirely disingenuous.

You've never met people who take what you now call obvious hyperbole absolutely seriously and literally?

I guess you're going to continue to get surprised by how often you get criticised in this specific way, by many, many other people.

Hint: when someone doesn't understand you, you were in fact not obvious, no matter what you think — communication is a multiplayer game, not a single-player endeavour.

I like unit tests, and I would happily adopt a CI system if my project included non-Python code and had to build multiple wheels. But formatting code properly in my editor is second nature by now; the functions I write are typically so short that it'd be hard to do anything a linter would object to; and type-checking doesn't just introduce busy-work, it works against part of the reason I'm using Python in the first place. I actively don't want to tell people not to call my code with a perfectly compatible type just because I hadn't considered it as within the range of possible compatible types.

No. On the occasions where I've tried to use an IDE for other programming languages, I've felt like it got in my way more than it helped; and Python is if anything designed more for IDE-less development (due to its overall elegance), and opposed to straightforward IDE guidance (due to its dynamicity).

> I've been using Python for right about 20 years now.

That's actually the biggest issue I've seen when a bit back joined a python-shop. Everyone there had mostly done python their whole careers. Fell in love with language during studies, then applied for jobs using that language. Stuck in the old ways, perhaps python felt nimble and nice 20 years ago compared to other things at the time, but with little progress (from its users) in using modern tooling it felt so arcane coming to this shop. And it wasn't the job's fault, it was a state of the art python stack, just a decade behind what other languages have.

I’ve been writing Python for 25 years and I love love love ruff and uv and friends.

Experienced Python folks have Stockholm Syndrome about its tooling, even rejoice at all the "options" for things like dependency managers.

> I know this is kinda the n+1 issue where astral is just adding another.

My bugbear with that XKCD is that even if it's true, it's also how progress is made. By this point I'm so annoyed whenever anyone links it that I kinda just wish Randall would take it down.

Yeah, and that comic is about standards anyways, not tools, so it's doubly annoying when it's linked out of context

> it's also how progress is made

Introducing n+1 solution/ standard may be the necessary cost of making progress, but it is possible to incur that cost without gaining anything

(at the extreme, trolling is fun activity with net negative on bigger scale)

Yeah but still seems relevant when complaining there are too many options and praising the n+1 option

I used to use any standard editor but these days I use PyCharm or Visual Studio (not Code) otherwise, I just use Sublime Text or any adjacent reasonable editor.

Elementary OS has the nicest editor that other Distros have not snatched up yet not sure why. Its fast, and fits the bill where KATE and Sublime Text are for me.

I started with python dependency management just executing pip install and thinking wow that's cool. No envs, no linters or formatters.

The point is, if you are learning to code, you can skip nearly all the ecosystem tools. Their need will arise when the time comes.

Yeah but a global environment is a really bad idea. It’s going to trip up those beginners when second project that requires a different version of pytorch.

And when they try to revisit their project one year later only to find it broken.

People just need a mentor. Could you imagine getting into plumbing and just trying to work out what kind of tools you need by looking at the pipes? Of course not. You'd learn from someone else.

I’ve been coding for 25 years. I don’t need a mentor. I want nice tools when I try yet another language.

I primarily work on typescript projects, little bit of go. Never enjoyed working with python until I found uv. Glad to see folks rally around astral's tools.

`uv` really is amazing.

This is why I tried ruff, managing the different settings and stuff and an experienced Python person was getting tedious. Now I have one tool.

I moved to poetry for things a bit ago until I found out about uv recently, it’s so fast I thought it didn’t even do what it asked a couple times.

Reply on news.ycombinator.com