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

61–70 of 581 posts

Re: Python developers are embracing type hints

#61

Post by skydhash »

maleldil wrote: post #48
skydhash wrote: post #4

Earlier quoted context omitted.

I do not program that much in python, but I believe the general accepted wisdom in dynamic languages was explicit name and load of documentations (as comments and docstrings).

> explicit name and load of documentations (as comments and docstrings). Which can be out of date are often missing. Might as well use type-hints that can be statically checked.

If the name of a function and its docstring is out of date, then what you have is a bad culture for coding. It’s up there with god classes in OOP.

Re: Python developers are embracing type hints

#62

Post by zahlman »

pansa2 wrote: post #58
zahlman wrote: post #55

It's the other way around, IMO: people who think the language should at least have type hints are now more willing to use it, now that there's better tooling for checking those hints.

Yes. And people who preferred the language (and its culture) before the "fundamental change" of adding type hints are now less willing to use it.

Probably some people are. I just mostly don't think about the annotations.

Re: Python developers are embracing type hints

#63

Post by aw1621107 »

dandiep wrote: post #54
AlienRobot wrote: post #49

Earlier quoted context omitted.

My love for python was critically hurt when I learned about typing.TYPE_CHECKING. For those unaware, due to the dynamic nature of Python, you declare a variable type like this foo: Type This might look like Typescript, but it isn't because "Type" is actually an object. In python classes and functions are first-class objects that you can pass around and assign to variables. The obvious problem of this is that you can…

Isn’t this solved in 3.14/PEP-649?

I want to say it (or something similar at least) was originally addressed by from __future__ import annotations back in Python 3.7/3.8 or thereabouts? I definitely remember having to use stringified types a while back but I haven't needed to for quite a while now.

Re: Python developers are embracing type hints

#64

Post by mjr00 »

zahlman wrote: post #57
mjr00 wrote: post #51

Earlier quoted context omitted.

The Reddit post falls under the case of "don't know" the type. If you want to allow users to pass in any objects, try to add and fail at runtime... that's exactly what Any is for. But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all.

> But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all. Was Tim Peters also wrong way back in the day when he counseled Guido van Rossum to allow floats to be added to integers without a cast, like other popular languages?

How is `float | int` anywhere close to equivalent to `Any`?

Re: Python developers are embracing type hints

#65

Post by pdonis »

mjr00 wrote: post #51
pdonis wrote: post #36

Earlier quoted context omitted.

> if you don't know or want to define the type That's not the issue the reddit post is raising. The reddit post is pointing out that what a "type" is is not as simple as it looks. Particularly in a language like Python where user-defined types proliferate, and can add dunder methods that affect statements that involve built-in operations. "Just use Any" doesn't solve any of those problems. > just use Any. All the abo…

The Reddit post falls under the case of "don't know" the type. If you want to allow users to pass in any objects, try to add and fail at runtime... that's exactly what Any is for. But the entire post is built upon the premise that accepting all types is good API design. Which it isn't, at all.

> The Reddit post falls under the case of "don't know" the type.

No, it doesn't. The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The problem is expressing that in Python's type notation in a way that catches all edge cases.

> If you want to allow users to pass in any objects, try to add and fail at runtime

Which is not what the post author wants to do. They want to find a way to use Python's type notation to catch those errors with the type checker, so they don't happen at runtime.

> the entire post is built upon the premise that accepting all types is good API design

It is based on no such thing. I don't know where you're getting that from.

Re: Python developers are embracing type hints

#66

Post by scuff3d »

fnord77 wrote: post #40
scuff3d wrote: post #23

Or you could just use a statically typed language and get a much better experience.

A entire class of bugs, wiped out by a thing called a "compiler". Gigahours of downtime and bug fixing globally prevented by a modest extra step up front. Great stuff.

I had someone say to me they preferred strict type checking in a Python linter over a statically typed language because they "don't like a build step"...

Dudes it's literally just worse compilation with extra steps.

Re: Python developers are embracing type hints

#67

Post by k3vinw »

I really think that Rust has one of the best designed/inspired type systems.

If I had to rewrite a Python project, I would consider Rust or another statically typed language before choosing to continue in a dynamic language with types bolted on. I hope the situation improves for dynamic languages with optional types, but it still feels weird and bolted onto the language because it is.

Re: Python developers are embracing type hints

#68

Post by dwattttt »

maleldil wrote: post #47
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…

> Need to iterate over a collection of things? Iterable[T] > Want to create a data object that maps any hashable type to just about anything else? Mapping[T, U]

Beyond the advantage that a type-checker/linter can tell if you're doing the right thing when writing those functions, it lets an IDE infer what type you're iterating over, in order to provide more support/completion/hinting/checks (without recursively analyzing arbitrary code, so: 'instantly' vs 'maybe not ever).

Re: Python developers are embracing type hints

#69

Post by sgarland »

aw1621107 wrote: post #63
dandiep wrote: post #54

Earlier quoted context omitted.

Isn’t this solved in 3.14/PEP-649?

I want to say it (or something similar at least) was originally addressed by from __future__ import annotations back in Python 3.7/3.8 or thereabouts? I definitely remember having to use stringified types a while back but I haven't needed to for quite a while now.

Yes, annotations allows you to use the declared types as they are, no strings.
Post reply on HN