Live data from Hacker News

Python developers are embracing type hints

pyrefly.org

331–340 of 581 posts

Re: Python developers are embracing type hints

#331

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

In my experience, the right tooling makes Python typing a big win. Modern IDEs give comprehensive real-time feedback on type errors, which is a big productivity boost and helps catch subtle bugs early (still nowhere near Rust, but valuable nonetheless). Push it too far though, and you end up with monsters like Callable[[Callable[P, Awaitable[T]]], TaskFunction[P, T]]. The art is knowing when to sprinkle types just enough to add clarity without clutter.

Re: Python developers are embracing type hints

#332
post #214

Earlier quoted context omitted.

>And, as you heavily imply in your post, type checkers won't be able to cope with it I implied no such thing. literally said there's a language that already does this. Typescript. IDE's cope with it just fine. >That's not a benefit. That's a monstrosity. So typescript is a monstrosity? Is that why most of the world who uses JS in node or the frontend has moved to TS? Think about it.

I don't believe Typescript (nor Idris) type systems work like you describe, though? Types aren't programmable with code like that (in the same universe, as you say) and TS is structurally typed, with type erasure (ie types are not available at runtime). I am not that deeply familiar with Python typings development but it sounds fundamentally different to the languages you compare to.

Typescript types (and Idris) are Turing complete. You can actually get typescript types to run doom.

https://www.youtube.com/watch?v=0mCsluv5FXA&t

Idris on the other hand is SPECIFICALLY designed so types and the program live in the same language. See the documentation intro: https://www.idris-lang.org/pages/example.html

THe powerful thing about these languages is that they can prove your program correct. For testing you can never verify your program to be correct.

Testing is a statistical sampling technique. To verify a program as correct via tests you have to test every possible input and output combination of your program, which is impractical. So instead people write tests for a subset of the possibilities which ONLY verifies the program as correct for that subset. Think about it. If you have a function:

    def add(x: int, y: int) -> int
How would you verify this program is 100% correct? You have to test every possible combination of x, y and add(x, y). But instead you test like 3 or 4 possibilities in your unit tests and this helps with the overall safety of the program because of statistical sampling. If a small sample of the logic is correct, it says something about the entire population of the logic..

Types on the other hand prove your program correct.

     def add(x: int, y: int) -> int:
         return x + y
If the above is type checked, your program is proven correct for ALL possible types. If those types are made more advanced via being programmable, then it becomes possible for type checking to prove your ENTIRE program correct.

Imagine:

     def add(x: A, y: B) -> A + B:
         return x + y
With a type checker that can analyze the above you can create a add function that at most can take an int that is Python on the other hand doesn't really have type checking. It has type hints. Those type hints can de defined in the same language space as python. So a type checker must read python to a limited extent in order to get the types. Python at the same time can also read those same types. It's just that python doesn't do any type checking with the types while the type checker doesn't do anything with the python code other than typecheck it.

Right now though, for most typecheckers, if you create a function in python that returns a typehint, the typechecker is not powerful enough to execute that function to find the final type. But this can certainly be done if there was a will because Idris has already done this.

Re: Python developers are embracing type hints

#333

Earlier quoted context omitted.

You're actually missing the benefit of this. It's actually a feature. With python, because types are part of python itself, they can thus be programmable. You can create a function that takes in a typehint and returns a new typehint. This is legal python. For example below I create a function that dynamically returns a type that restricts a Dictionary to have a specific key and value. from typing import TypedDict def…

Are there really productive projects which rely on types as a proofing system? I've always thought it added too much complexity to the code, but I'd love to see it working well somewhere. I love the idea of correctness by design.

No too my knowledge nothing is strict about a proofing system because like I said it becomes hard to do. It could be useful for ultra safe software but for most cases the complexity isn't worth it.

But that doesn't mean it's not useful to have this capability as part of your typesystem. It just doesn't need to be fully utilized.

You don't need to program a type that proves everything correct. You can program and make sure aspects of the program are MORE correct than just plain old types. typescript is a language that does this and it is very common to find types in typescript that are more "proofy" than regular types in other languages.

See here: https://www.hacklewayne.com/dependent-types-in-typescript-se...

Typescript does this. Above there's a type that's only a couple of lines long that proves a string reversal function reverses a string. I think even going that deep is overkill but you can define things like Objects that must contain a key of a specific string where the value is either a string or a number. And then you can create a function that dynamically specifies the value of the key in TS.

I think TS is a good example of a language that practically uses proof based types. The syntax is terrible enough that it prevents people from going overboard with it and the result is the most practical application of proof based typing that I seen. What typescript tells us that proof based typing need only be sprinkled throughout your code, it shouldn't take it all over.

Re: Python developers are embracing type hints

#334
post #25

The thing that finally got me on board with optional type hints in Python was realizing that they're mainly valuable as documentation. But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful.

Type hints as documentation are a gateway drug to type hints for bug finding. Keep at it :)

Re: Python developers are embracing type hints

#335

Python types - all the onus of static types, with none of the performance! I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props. Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type…

What does "multiple constructors" buy you that you can't get from multiple static methods that return an object of the enclosing class's type. Maybe I'm missing out on something cool...

Perhaps just a fuzzy feeling. I suppose I haven’t tried using static methods for that purpose. Will give it a shot!

Re: Python developers are embracing type hints

#337
post #11

Earlier quoted context omitted.

With the newest Python versions, most of the time I don't need typing imports!

Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...

> List, Duct, Tuple...

I'm aware this is just a typo but since a lot of the Python I write is in connection with Airflow I'm now in search of a way to embrace duct typing.

Re: Python developers are embracing type hints

#338

Python types - all the onus of static types, with none of the performance! I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props. Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type…

One shouldn't be implementing anything "trully OOP" to begin with...

Quotes speak louder than words… However it’s hard to say “what one should or shouldn’t” be implementing in general terms.

Re: Python developers are embracing type hints

#340

Earlier quoted context omitted.

Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, even if the end-goal is to ship an api with clear type signatures. There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. > Many old school python d…

> There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. My hunch is that the people who see no downsides whatsoever in static typing are those who mostly just consume APIs.

There are downsides. But the upsides outweigh the downsides.

I'm not a consumer of APIs. I've done game programming, robotics, embedded system development (with C++ and rust), (web development frontend with react/without react, with jquery, with angurar, with typescript, with js, zod) (web development backend with golang, haskell, nodejs typescript, and lots and lots of python with many of the most popular frameworks with flask + sqlalchemy, django, FastApi + pydantic, )

I've done a lot. I can tell you. If you don't see how types outweigh untyped languages, you're a programmer with experience heavily weighed toward untyped programming. You don't have balanced experience to make a good judgement. Usually these people have a "data scientist" background. Data analyst or data scientist or machine learning engineers... etc. These guys start programing heavily in the python world WITHOUT types and they develop unbalanced opinions shaped by their initial styles of programming. If this describes you, then stop and think... I'm probably right.

Post reply on HN