Everything that isn't uv, ty, ruff is wrong and deprecated
Will you update the list for us, a month from now?
Are you expected to run five Python type-checkers now?
121–130 of 220 posts
Re: Are you expected to run five Python type-checkers now?
#122Earlier quoted context omitted.
It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…
This is even worse because you attempt to try to sell why types SOMETIMES make sense. But you aim with this for a language that did not have nor need types to begin with. People don't seem to understand that this is an issue. The library-situation is really not different from having types everywhere, and some people will do that too. > catch bugs that you might otherwise miss. People repeat this a lot. In about 22 ye…
> In about 22 years of writing ruby code, I have never ran into a situation once where I would have caught a bug through types
You must be the world's greatest programmer with perfect memory. Every nil pointer exception is a bug a (good) type checker could have caught. You've never had a NameError or NoMethodError in Ruby?
Re: Are you expected to run five Python type-checkers now?
#123Dynamically typed languages are going to decline with the rise of AI coding. Statically typed languages provide the determinism necessary to efficiently anchor probabalistic coding agents. You can throw as much type checking at dynamic languages after the fact, but youre just going to burn energy (and tokens) doing what another language gets 'for free'.
I am not so sure that's this simple. No matter your preference, programs in dynamically typed languages are still very much deterministic. To be able to reason about the output of LLMs (though it is debatable how often will this be needed), you want the output from your imprecise human language spec to a deterministic spec (code) to be as easy to review as possible (for correctness, but mostly for any glaring errors)…
Static type checking catches a whole class of programming errors for free. Writing tests costs tokens or human time, so you end up needing more code (and probably more CPU time) to achieve the same level of error-checking in a dynamic language.
Re: Are you expected to run five Python type-checkers now?
#124This is what the typing spec says about type narrowing[1]:
"Type checkers should narrow the types of expressions in certain contexts. This behavior is currently largely unspecified."
Have fun.
[1] https://typing.python.org/en/latest/spec/narrowing.html#type...
Re: Are you expected to run five Python type-checkers now?
#125Earlier quoted context omitted.
It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…
This is even worse because you attempt to try to sell why types SOMETIMES make sense. But you aim with this for a language that did not have nor need types to begin with. People don't seem to understand that this is an issue. The library-situation is really not different from having types everywhere, and some people will do that too. > catch bugs that you might otherwise miss. People repeat this a lot. In about 22 ye…
Your app didn't silently break when you upgrade rails or any other gem?
If ruby was statically typed the typechecker would have caught it.
Re: Are you expected to run five Python type-checkers now?
#126Earlier quoted context omitted.
What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.
Well, that's the curse of machine learning: since everyone uses Python you have to deal with Python. Even though Python isn't very nice when things start to get serious and you don't want to spend your time fiddling with noise just to make something work at scale. I'd wish the ML/AI/LLM crowd would see that it is in their interest to get better developer ergonomics at scale. (I don't want to have to turn to C++)
Anything performance sensitive ends up being an extension in compiled code anyway
Python is mostly just glue
Re: Are you expected to run five Python type-checkers now?
#127Earlier quoted context omitted.
How so?
With writing code in english now, why have it use a slow weak language? ML still has a depth of libraries that can't be replicated easily but ML work is decreasing by the day with LLMs.
Because the English to code translation step is fallible
Re: Are you expected to run five Python type-checkers now?
#128Earlier quoted context omitted.
But why does your appreciate of type systesm not lead you to something like Typescript? Which is a lot more robust? Or Rust? C#? I guess my speculation is that not every language is good at everything. Sure you might want a better type system with Rust. But for data science?
In practice, inertia is stopping me. For personal projects, I don't want to learn Rust just so I can do `def add(a: int, b: int) -> int`. For work, I don't really get a choice. I work on brownfield projects. We do use TypeScript, thankfully, for all the browser bits. But nobody is going to stop to refactor a 5 year old production code base from Python to Go just for better types. And -- pepega -- definitely not our c…
Meh, the amount of effort required to keep up to date with the python ecosystem churn is around the same as learning rust. More so if you are starting from scratch.
I quit python after realizing the amount of effort it required to just implement the tooling for a project… when all of that comes included with rust. I have spent maybe an hour in the last year thinking about tooling. Glorious.
But yeah, I feel for you. It is an impossible sell when they pay off is impossible to understand without a Time Machine and the only thing known about the cost is that it’s high. But for new people and projects, I can’t imagine starting with python in 2026.
Re: Are you expected to run five Python type-checkers now?
#129Earlier quoted context omitted.
It's not an all or nothing thing. I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not. Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and ca…
Yes, where would I be without the _RelationshipBackPopulatesArgument type of sqlalchemy.orm.relationship(argument: _RelationshipArgumentType[Any] | None = None, secondary: _RelationshipSecondaryArgument | None = None, *, uselist: bool | None = None, collection_class: Type[Collection[Any]] | Callable[[], Collection[Any]] | None = None, primaryjoin: _RelationshipJoinConditionArgument | None = None, secondaryjoin: _Rela…
_RelationshipBackPopulatesArgument = Union[
str,
PropComparator[Any],
Callable[[], Union[str, PropComparator[Any]]],
]
Re: Are you expected to run five Python type-checkers now?
#130Earlier quoted context omitted.
> happen to be working over the past couple days in typed Python for the first time. It's kind of nice. I like it. I like me a good type system and have always hated about everything about types in Python. What do you find nice and like about it? (My experience with Python: all the type checkers are broken, there are false positives and false negatives everywhere. The LSPs are likewise broken, I have not found one th…
Lack of typing is my biggest problem with Python, Ruby, and ES6 Javascript; I have to write everything twice, once to do the stuff I want, and once to double check that it's actually doing stuff, because a single typo blow the program up despite it parsing fine. Python typing is easy to dip in and out of. It handles None nicely; not as nicely as a true Optional, but enough for daily driving. The annotations are reada…
I believe you are right to point out how you feel about some of these features of a particular language, and to let that guide your decision in how and whether you use them.
It does not, however, say anything about the actual productivity gain or loss of using types in a language like Python which does not require them — that should be the ultimate objective measure of whether they make sense or not.
With most languages, I get annoyed if I need to create separate types for every variant of a basic type (eg. let's have a firstNameString, familyNameString, CountryCodeString, CountryNameString... when is it too much?) - I do not think there is any way someone can prove going this deep improves maintainability long term. Eg. imagine you introduced validation of CountryCodeString based on ISO-3166, and there has been a change to ISO-3166 which happen every couple of years — how do you start supporting new codes? How do you deprecate and remove old ones? All of those are not helped with a type being very strict, you still have the persistent data to worry about, code actually supporting any of those, etc — the basic type check is trivial with a couple of small unit tests in comparison. You also quickly venture into a territory of complex types with complex interaction rules (this subvalue can be one of A if another one is X; but B if another is Y).
So for me covering the basic invariants with a unit test is not much more effort and — especially with Python — does not stop one from refactoring effectively and building stable, long-running systems.
Really, complex relationships in data are complex, and encoding it in a declarative way using a complex schema does not guarantee correctness (see Pydantic); if you want just very basic data conformance (type) checking, it's mostly a question of ergonomics.
Basically, you need to keep to some principles of code structure and architecture, but they are a simple set of principles — perhaps the fact that most Python projects do not abide by these should be a knock against Python? I only attribute it to the approachability of Python, but I am open to being wrong and this being the latent forced idiomatic use that projects always evolve into?