Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python developers are embracing type hints

pyrefly.org

Post reply on HN
Print view View original

501–510 of 581 posts

Re: Python developers are embracing type hints

#501

Post by screye »

seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

AI tab-complete & fast LSP implementations made typing easy. The tools changed, and people changed their minds.

JSON's interaction with types is still annoying. A deserialized JSON could be any type. I wish there was a standard python library that deserialized all JSON into dicts, with opinionated coercing of the other types. Yes, a custom normalizer is 10 lines of code. But, custom implementations run into the '15 competing standards' problem.

Actually, there should be a popular type-coercion library that deals with a bunch of these annoying scenarios. I'd evangelize it.

Re: Python developers are embracing type hints

#503

Post by MangoToupe »

loglog wrote: post #470
MangoToupe wrote: post #377

Earlier quoted context omitted.

> There is nothing about types that would make incremental develpment harder. Oh, please, this is either lack of imagination or lack of effort to think. You've never wanted to test a subset of a library halfway through a refactor?

Yes, type checkers are very good at tracking refactoring progress. If it turns out that you can proceed to test some subset, then congratulations, you found a new submodule.

I am continually astounded by the stubborn incuriosity of humans with a bone to pick.

Re: Python developers are embracing type hints

#504

Post by jkrejcha »

makeitdouble wrote: post #494
jkrejcha wrote: post #486

Earlier quoted context omitted.

Generally using the Protocol[1] feature from typing import Protocol class SupportsQuack(Protocol): def quack(self) -> None: ... This of course works with dunder methods and such. Also you can annotate with @runtime_checkable (also from typing) to make `isinstance`, etc work with it [1]: https://typing.python.org/en/latest/spec/protocol.html

You're then creating a Protocol for every single function that could rely on some duck typing. Imagine one of your function just wants to move an iterator forward, and another just wants the current position. You're stuck with either requiring a full iterator interface when only part of it is needed or create one protocol for each function. In day to day life that's dev time that doesn't come back as people are now s…

For the collections case in particular, you can use the ABCs for collections that exist already[1]. There's probably in your use case that satisfies those. There's also similar things for the numeric tower[2]. SupportsGE/SupportsGT/etc should probably be in the stdlib but you can import them from typeshed like so

    from __future__ import annotations

    from typing import TYPE_CHECKING

    if TYPE_CHECKING:
        from _typeshed import SupportsGT
---

In the abstract sense though, most code in general can't work with anything that quack()s or it would be incorrect to. The flip method on an penguin's flipper in a hypothetical animallib would probably have different implications than the flip method in a hypothetical lightswitchlib.

Or less by analogy, adding two numbers is semantically different than adding two tuples/str/bytes or what have you. It makes sense to consider the domain modeling of the inputs rather than just the absolute minimum viable to make it past the runtime method checks.

But failing that, there's always just Any if you legitimately want to allow any input (but this is costly as it effectively disables type checking for that variable) and is potentially an indication of some other issue.

[1]: https://docs.python.org/3.14/library/collections.abc.html

[2]: https://docs.python.org/3/library/numbers.html

Re: Python developers are embracing type hints

#505

Post by emeryberger »

EdwardDiego wrote: post #81
a_t48 wrote: post #79

Has anyone had good luck with auto-annotation of types of existing codebases? Either via LLM or via various runtime hooks? I work in a codebase that started off in Python 2 and isn't annotated with types in the majority of places, and I feel the pain every time I have to wonder what exactly the arguments to a method is.

Yep, I've used this pretty successfully, the ideal is to run it under realistic prod traffic over time to capture as many types as can flow into a given function, but a good set of unit/integration tests can also provide good coverage. And if you re-use the same type store (SQLite DB) across multiple instrumented runs, you can further improve it. https://github.com/Instagram/MonkeyType

RightTyper is much better in addition to running orders of magnitude faster.

https://github.com/RightTyper/RightTyper

(full disclosure, I am one of its authors).

Re: Python developers are embracing type hints

#506

Post by tdeck »

boltzmann64 wrote: post #483
tdeck wrote: post #253

Earlier quoted context omitted.

I like Python a lot, and have been using it for personal projects since about 2010. It was only once I started working and encountering long-lived unfamiliar Python codebases regularly that I understood the benefits of type hints. It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. It's even less fun to find out that someone ma…

I am sorry, but whats wrong with doing something like, `print(type(var)); exit()` and just running it once instead of digging through 5-6 stack frames?

Sometimes a function's input or return type can vary depending on the execution path? Also, inserting print statements is often not practical when working on web backend software which is kind of a big thing nowadays. If you can run the service locally, which is not a given, dependencies get mocked out and there's no guarantee that your code path will execute or that the data flowing through it will be representative.

Re: Python developers are embracing type hints

#507

Post by scuff3d »

chpatrick wrote: post #476
scuff3d wrote: post #431

Earlier quoted context omitted.

No you don't. You get the illusion of static types without the actual upsides. For any even medium sized project or anything where you work with other developers a statically typed language is always going to be better. We slapped a bunch of crap on Python to make it tolerable, but nothing more.

I disagree and I've been using Haskell professionally for ten years so I know what I'm talking about when it comes to types. Typed Python isn't perfect but it's totally workable with medium sized projects and gives you access to a great ecosystem.

Everyone knows Haskell is only used for white papers :p

Yeah it's workable, and better than nothing. But it's not better than having an actual static type system.

1. It's optional. Even if you get your team on board you are inevitably going to have to work with libraries that don't use type hints

2. It's inconsistent, which makes sense given that it's tacked onto a language never intended for it.

3. I have seen some truly goofy shit written to make the linter happy in more complex situations.

I honestly think everything that's been done to try to make Python more sane outside outside scripting or small projects (and the same applies to JS and TS) are a net negative. Yes it has made those specific ecosystems better and more useful, but it's removed the incentive to move to better technology/languages actually made to do the job.

Re: Python developers are embracing type hints

#508

Post by ninetyninenine »

MangoToupe wrote: post #503
loglog wrote: post #470

Earlier quoted context omitted.

Yes, type checkers are very good at tracking refactoring progress. If it turns out that you can proceed to test some subset, then congratulations, you found a new submodule.

I am continually astounded by the stubborn incuriosity of humans with a bone to pick.

What in the world are you talking about. Please specify how lack of types helped you in your aforementioned scenario.

I don't think it's a lack of curiosity from others. But it's more like fundamental lack of knowledge from you. Let's hear it. What is it are you actually talking about? Testing a subset of a library halfway though a refactor? How does a lack of types help with that?

Re: Python developers are embracing type hints

#509

Post by dragonwriter »

makeitdouble wrote: post #494
jkrejcha wrote: post #486

Earlier quoted context omitted.

Generally using the Protocol[1] feature from typing import Protocol class SupportsQuack(Protocol): def quack(self) -> None: ... This of course works with dunder methods and such. Also you can annotate with @runtime_checkable (also from typing) to make `isinstance`, etc work with it [1]: https://typing.python.org/en/latest/spec/protocol.html

You're then creating a Protocol for every single function that could rely on some duck typing. Imagine one of your function just wants to move an iterator forward, and another just wants the current position. You're stuck with either requiring a full iterator interface when only part of it is needed or create one protocol for each function. In day to day life that's dev time that doesn't come back as people are now s…

> You're then creating a Protocol for every single function that could rely on some duck typing.

No, you are creating a Protocol (the kind of Python type) for every protocol (the descriptive thing the type represents) that is relied on for which an appropriate Protocol doesn’t already exist. Most protocols are used in more than one place, and many common ones are predefined in the typing module in the standard library.

Re: Python developers are embracing type hints

#510

Post by oivey »

joshribakoff wrote: post #484
oivey wrote: post #423

Earlier quoted context omitted.

> That's your problem right there. Why are random callers sending whatever different input types to that function? Because it’s nice to reuse code. I’m not sure why anyone would think this is a design issue, especially in a language like Python where structural subtyping (duck typing) is the norm. If I wanted inheritance soup, I’d write Java. Ironically, that’s support for structural subtyping is why Protocols exist.…

Why can’t you re-use it with limited types? If the types are too numerous/hard to maintain it seems like the same would apply to the runtime code.

Because it’s nice to reuse code. It’s virtually never the case that a function being compatible with too many types is an issue. The issue is sometimes that it isn’t clear what types will be compatible with a function, and people make mistakes.

Python’s type system is overall pretty weak, but with any static language at least one of the issues is that the type system can’t express all useful and safe constructs. This leads to poor code reuse and lots of boilerplate.

Post reply on HN