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

511–520 of 581 posts

Re: Python developers are embracing type hints

#511

Post by dragonwriter »

thr0w4w4y1337 wrote: post #221
Dr_Birdbrain wrote: post #215

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…

from typing import Protocol, TypeVar T_co = TypeVar("T_co", covariant=True) class Indexable(Protocol[T_co]): def __getitem__(self, i: int) -> T_co: ... def f(x: Indexable[str]) -> None: print(x[0]) I am failing to format it proprely here, but you get the idea.

As of Python 3.12, you don’t need separately declared TypeVars with explicit variance specifications, you can use the improved generic type parameter syntax and variance inference.

So, just:

  class Indexable[T](Protocol):
    def __getitem__(self, i: int,/) -> T: ...
is enough.

Re: Python developers are embracing type hints

#512

Post by dragonwriter »

sevensor wrote: post #325
thr0w4w4y1337 wrote: post #231

Earlier quoted context omitted.

Sequence does not cut it, since the op mentioned int indexed dictionaries. But yeah.

Sequence[SupportsFloat] | Mapping[int,SupportsFloat] Whether or not you explicitly write out the type, I find that functions with this sort of signature often end up with code that checks the type of the arguments at runtime anyway. This is expensive and kind of pointless. Beware of bogus polymorphism. You might as well write two functions a lot of the time. In fact, the type system may be gently prodding you to ask…

> Sequence[SupportsFloat] | Mapping[int,SupportsFloat]

This is really just the same mistake as the original expanding union, but with overly narrow abstract types instead of overly narrow concrete types. If it relies on “we can use indexing with an int and get out something whose type we don’t care about”, then its a Protocol with the following method:

  def __getitem__(self, i: int, /) -> Any: ...
More generally, even if there is a specific output type when indexing, or the output type of indexing can vary but in a way that impacts the output or other input types of the function, it is a protocol with a type parameter T and this method:

  def __getitem__(self, i: int, /) -> T: ...
It doesn’t need to be union of all possible concrete and/or abstract types that happen to satisfy that protocol, because it can be expressed succinctly and accurately in a single Protocol.

Re: Python developers are embracing type hints

#513

Post by dragonwriter »

TZubiri wrote: post #287
Dr_Birdbrain wrote: post #215

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…

So the type is anything that implements the index function ([], or __getitem__), I thnink that's a Sequence, similar to Iterable. >from typing import Sequence >def third(something: Sequence): > return indexable[3] however if all you are doing is just iterate over the thing, what you actually need is an Iterable >from typing import Iterable >def average(something:Iterable): > for thing in something: > ... Statisticall…

> So the type is anything that implements the index function ([], or __getitem__), I thnink that's a Sequence

Sequence involves more than just __getitem__ with an int index, so if it really is anything int indexable, a lighter protocol with just that method will be more accurate, both ar conveying intent and at avoiding needing to evolve into an odd union type because you have something that a satisfies the function’s needs but not the originally-defined type.

Re: Python developers are embracing type hints

#514

Post by dragonwriter »

lukaslalinsky wrote: post #95

I was extremely skeptical when typing was introduced. What's the point if runtime ignores them. I forced myself to use them as documentation and now I'm on the other side of the spectrum, all code should have them. It already helped me a lot during refactors and I always wished more code had types. I think the same is true for AIs, they will benefit from having the types explicitly said. It's a shame they currently d…

> What's the point if runtime ignores them.

Ideally, with static checking, the runtime shouldnn’t need to care about types because cide that typechecks shouldn’t be capable of not behaving according to the types declared.

Python, even with the most restrictive settings in nost typecheckers, may not quite achieve that, but it certainly reeuces the chance of surprises lf that kind compared to typing information in docstrings, or just locked away in the unststed assumptions of some developer.

Re: Python developers are embracing type hints

#515

Post by dragonwriter »

iandanforth wrote: post #45

I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams. Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As lon…

> Duck typing is one of the best things about Python.

And duck typing with the expected contract made explicit and subject to static verification (and IDE hinting, etc.) is one of the best things about Python typing.

> If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen

I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types (but I also like that typing being optional means that its very easy to toss out exploratory code before settling on how something new should work.)

Re: Python developers are embracing type hints

#516

Post by dragonwriter »

jgb1984 wrote: post #201
pansa2 wrote: post #131

Earlier quoted context omitted.

As the article says, type hints represent a fundamental change in the way Python is written. Most developers seem to prefer this new approach (especially those who’d rather be writing Java, but are stuck using Python because of its libraries). However it is indeed annoying for those of us who liked writing Python 2.x-style dynamically-typed executable pseudocode. The community is now actively opposed to writing that…

There is nothing python-2 about my python-3 dynamically typed code. I'm pretty confident a majority of new python code is still being written without type hints. Hell, python type annotations were only introduced in python 3.5, the language was 24 years old by then! So no, the way I write python is the way it was meant to be, type hints are the gadget that was bolted on when the language was already fully matured, it…

> Hell, python type annotations were only introduced in python 3.5

Mypy was introduced with support for both for Python 2.x and 3.x (3.2 was the current) using type comments before Python introduced a standard way of using Python 3.0’s annotation syntax for typing; even when type annotations were added to Python proper, some uses now supported by them were left to mypy-style type comments in PEP 484/Python 3.5, with type annotations for variables added in PEP 526/Python 3.6.

Re: Python developers are embracing type hints

#517

Post by rkomorn »

dragonwriter wrote: post #515
iandanforth wrote: post #45

I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams. Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As lon…

> Duck typing is one of the best things about Python. And duck typing with the expected contract made explicit and subject to static verification (and IDE hinting, etc.) is one of the best things about Python typing. > If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen I find I end up at any given level of bug fr…

> I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types

Same.

Type hints also basically give me a "don't even bother running this if my IDE shows type warnings" habit that speeds up python development.

Absence of warnings doesn't guarantee me bug-free code but presence of warnings pretty much guarantees me buggy code.

Type hints are a cheap way to reduce (not eliminate) run time problems.

Re: Python developers are embracing type hints

#518

Post by runeblaze »

sota_pop wrote: post #317

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…

Python types - all the onus of static types, with none of the power of calculus of constructions. /s

Re: Python developers are embracing type hints

#519

Post by dragonwriter »

jmward01 wrote: post #53

Type hints in python are just that, hints. Use them to help with clarity but enforcing them and requiring them everywhere generally leads to the worst of all worlds. Lots of boilerplate, less readable code and throwing away many of the features that make python powerful. Use the best language for the job and use the right language features at the right time. I see too many black or white arguments in the developer co…

> Lots of boilerplate, less readable code and throwing away many of the features that make python powerful.

IMO, that complaint almost always goes with overuse of concrete types when abstract (Protocol/ABC) types are more accurate to the function of the code.

There was a time that that was a limitation in Python typing, but that that hasn’t been true for almost as long as Python typing had been available at all before it stopped being true.

Re: Python developers are embracing type hints

#520

Post by dirkc »

procaryote wrote: post #274
jmorenoamor wrote: post #157

Earlier quoted context omitted.

Coming from Java extreme verbosity, I just loved the freedom of python 20 years ago. Working with complex structures with mixed types was a breeze. Yes, it was your responsibility to keep track of correctness, but that also taught me to write better code, and better tests.

Writing tests is harder work than writing the equvalent number of type hints though

Type hints and/or stronger typing in other languages are not good substitutes for testing. I sometimes worry that teams with strong preferences for strong typing have a false sense of security.
Post reply on HN