What is this saying differently from https://peps.python.org/pep-0827/ ?
Are you expected to run five Python type-checkers now?
131–140 of 220 posts
Re: Are you expected to run five Python type-checkers now?
#132What is this saying differently from https://peps.python.org/pep-0827/ ?
Everything? The blog post and PEP have almost nothing to do with each other lol
Re: Are you expected to run five Python type-checkers now?
#133If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
Python has other, bigger problems that make it a constant headache. One of them being the dismissive attitude towards any and all of problems that come from versioning, dependencies and quirks that make it challenging to have robustness. Criticisms are typically dismissed by suggesting heaping yet another "solution" onto the growing pile of "solutions" that you have to drag around with you. That people have to learn.…
What are the problems you have with tooling? Imo it's no worse than most other languages besides a very small handful of recent ones (rust, go) where everything is included
The easy approach is usually just throw it in an OCI container
There's not much concrete to go on here besides "I don't like the ergonomics"
Re: Are you expected to run five Python type-checkers now?
#134Earlier quoted context omitted.
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.
Very simplistic look, IMO. I'll add another one mostly as a counterpoint (not that I believe it is strictly true, but largely yes!).
Python is a lot more expressive than other languages and has a very terse syntax, and thus requires LLM to output much fewer tokens to achieve the same job compared to other languages.
Adding a few more tests to ensure data conformity on top of what you have to do anyway with a statically typed language still results in fewer tokens overall.
Re: Are you expected to run five Python type-checkers now?
#135Earlier quoted context omitted.
Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.
Personally I like having my TypeScript cake and eating it. I also truly believe those who design type systems would benefit from taking a look what kind of code people programming in dynamically-typed languages produce.
I find it funnysad that python people coined the phrase duck typing and then ended up designing what they have now. Meanwhile TS manages to embody duck typing far better even though coming from very different background.
Re: Are you expected to run five Python type-checkers now?
#136The whole type checking experience in python has disappointed me deeply and is seriously affecting my work.
I see the appeal for type-checking and yeah it has caught many bugs. But the language is quickly running blindly to the worst of all worlds in regards to typing.
1. You have to exhaustively write types in many cases where they can be obviously inferred.
2. The type checking is just a lint step. i.e. we are still paying for the duck typed typing system.
3. We no longer get to use the duck typed typing system making a lot of generic code require obscure annotation incantations to pass the lint check while it's correct python code.
My ideal typing system would be around constraints introduced by the code and completely inferred unless the user wants to tighten the constraints. i.e
Instead of
def foo(a: int, b: int) -> int:
return a + b
def foo(a, b):
return a + b
It would tell you that there is no + operator for int and dictionary that is required by the foo function.
My ideal typing system would allow you to constraint the types as well like so
def foo(a: int, b: int):
return a + b
Re: Are you expected to run five Python type-checkers now?
#137If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
ML
Data tooling
Talent pool
Libraries for customers
Brownfield codebases
Academics
I can keep going…
Re: Are you expected to run five Python type-checkers now?
#138If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.
Totally agree. I hear a lot of rust makes it hard to write incorrect programs. In my experience it makes it hard to write programs in general.
Re: Are you expected to run five Python type-checkers now?
#139Five different type-checkers and even type-checking projects think adding multiple "ignores" is sound code. Typescript would allow overloads without ignores, for example.
Python's type checking ecosystem truly is a mess.
Re: Are you expected to run five Python type-checkers now?
#140Dynamically 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'.
Python is dynamically, strongly typed. It cares a lot about the types of its objects, you can't just mix and match at will.
Perhaps you meant statically typed?