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.
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.
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.
The more of this you can automate, the more you get to spend on "real work".
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 have yet to find a single drawback of adopting mypy (or similars) that isn’t completely eclipsed by the benefits.
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 guess that makes one of us.
Getting stuff working is much more important. I'd rather people concentrate on stuff like CI, Unit Tests and Deployments.
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.
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.
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.
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.