Hacker News Reader

Comment by zahlman | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com