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

Python type hints may not be not for me in practice

utcc.utoronto.ca

Post reply on HN
Print view View original

191–200 of 209 posts

Re: Python type hints may not be not for me in practice

#191

Post by pansa2 »

maleldil wrote: post #186
pansa2 wrote: post #120

The biggest issue with Python type hints for me isn't the hints themselves, it's that they encourage people to write overly complex, verbose code just to satisfy the type checker. Code like this [0] could simply be 3 functions. Instead it's 3 classes, plus a base class `AstNode`, just so the author can appease the type checker by writing `body: List[AstNode]` instead of the dynamically-typed `body = []`. [0] https://…

Writing `body: list[AstNode]` lets you statically know what elements you'll get when you do `body[i]` or iterate over it. If you don't specify the type, you don't know what you're getting, and you have to rely on always passing the correct objects around. I'm sure you've faced bugs where you expected something from a list and got something else. Note that you only need `body: list[AstNode] = []` if you declare an emp…

> Writing `body: list[AstNode]` lets you statically know what elements you'll get when you do `body[i]`

Don't get me wrong, I understand the benefit of the type hint - and if typing `: list[AstNode]` was all it took to get that benefit it would be a no-brainer. But that's not all it took - instead, to pass the type checker the entire script has become twice as long as it needs to be. The actual logic is hidden among multiple class definitions which are all unnecessary except to satisfy the type checker.

I agree with Armin Ronacher [0]: "types add value and they add cost". Perhaps the cost is worth paying for most programs - but there are plenty of other languages that support that way of working. For those programs where the cost might outweigh the benefits, I used to love writing Python as a more concise alternative to those languages - but instead nowadays it has become a poor attempt at mimicking them.

[0] https://lucumr.pocoo.org/2023/12/1/the-python-that-was/

Re: Python type hints may not be not for me in practice

#192

Post by pansa2 »

ahaferburg wrote: post #190
aegis4244 wrote: post #2

Is that a double negative in your title ? Or is it an inside joke I didn't get ?

I think it's a typo. The original title is "Python type hints may not be for me in practice". Dang, could you change it?

The title of the article itself has been edited to remove the double negative

Re: Python type hints may not be not for me in practice

#193

Post by IshKebab »

hbrn wrote: post #76
IshKebab wrote: post #71

Earlier quoted context omitted.

Nonsense. You might consider it a tradeoff, but it's a very heavily skewed one. Minor downsides on one side, huge upsides on the other. Also I would say type hints sacrifice aesthetics, not readability. Most code with type hints is easier to read, in the same way that graphs with labelled axes and units are easier to read. They might have more "stuff" there which people might think is ugly, but they convey critical i…

> Most code with type hints is easier to read That has not been my experience in the past few years. I've always been a fan of type hints in Python: intention behind them was to contribute to readability and when developer had that intention in mind, they worked really well. However, with the release of mypy and Typescript, engineering culture largely shifted towards "typing is a virtue" mindset. Type hints are no lo…

> intention behind them was to contribute to readability

This is provably wrong. See https://peps.python.org/pep-3107/#use-cases

Re: Python type hints may not be not for me in practice

#194

Post by maleldil »

pansa2 wrote: post #191
maleldil wrote: post #186

Earlier quoted context omitted.

Writing `body: list[AstNode]` lets you statically know what elements you'll get when you do `body[i]` or iterate over it. If you don't specify the type, you don't know what you're getting, and you have to rely on always passing the correct objects around. I'm sure you've faced bugs where you expected something from a list and got something else. Note that you only need `body: list[AstNode] = []` if you declare an emp…

> Writing `body: list[AstNode]` lets you statically know what elements you'll get when you do `body[i]` Don't get me wrong, I understand the benefit of the type hint - and if typing `: list[AstNode]` was all it took to get that benefit it would be a no-brainer. But that's not all it took - instead, to pass the type checker the entire script has become twice as long as it needs to be. The actual logic is hidden among…

> there are plenty of other languages that support that way of working

I'd use them if I could, but I'm trapped in Python for several reasons. If I could use Rust, Ocaml, etc., I'd do that. But my choice is between untyped and typed Python only, and I strongly believe that typed Python is much better.

Re: Python type hints may not be not for me in practice

#195

Post by never_inline »

joeyagreco wrote: post #77

> After the code has stabilized I can probably go back to write type hints [...] but I'm not sure that this would provide very much value. I think most developers who revisit their projects 6+ months later would disagree with the second part of this statement. My typical flow for "quick scripts" is: on first pass I'll add basic type hints (typing ":str" after a func param takes .2 seconds) for more complex data struc…

> for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine

One of the reason I use typing is IDE completion and error highlighting. For that purpose - I make sure to annotate even the obvious primitive types and for API responses, I find that defining a Pydantic model works very well.

Re: Python type hints may not be not for me in practice

#196

Post by never_inline »

belorn wrote: post #37
tasn wrote: post #21

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

Looking at that blog post, I find it illustrative in how people who like strong types and people who dislike strong types are addressing different form of bugs. If the main types of issues comes from bugs like 1 + "2" == 12" , then strong types is a big help. It also enables many developers who spend the majority of time in a programming editor to quickly get automatic help with such bugs. The other side is those peo…

I am grug

I use type hint press dot button get auto completes

https://grugbrain.dev/

Re: Python type hints may not be not for me in practice

#197

Post by never_inline »

Chris_Newton wrote: post #126
maleldil wrote: post #88

Earlier quoted context omitted.

> What is missing is mainstream adoption in libraries which is a matter of time. I don't think that's a big problem anymore. Between typeshed and typing's overall momentum, most libraries have at least decent typing and those that don't often have typed alternatives.

I don't think that's a big problem anymore. ORMs have entered the chat… These sometimes use a lot of dynamic modification, such as adding implicit ID fields or adding properties to navigate a relationship with another type that is defined in code only from the other side. It can also be awkward to deal with “not null” database fields if the way the ORM model classes are defined means fields are nullable as far as the…

The approach I have found to work is isolate the logic which deals with ORM models, and convert them to/from typed models (eg pydantic) at the function boundary.

with sqlalchemy mapped_column, its less of an issue. django, otoh, seems too much magic for static type. (happy to be proven wrong).

Re: Python type hints may not be not for me in practice

#198

Post by solidsnack9000 »

throwitaway1123 wrote: post #70
solidsnack9000 wrote: post #57

It seems like the author is looking for the ability to specify types as `typeof :arguments` and `typeof :return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.

TypeScript has the equivalent of what you're describing via the `Parameters` and `ReturnType` utility types [1][2], and I've found these types indispensable. So you can do the following: type R = ReturnType type P = Parameters [1] https://www.typescriptlang.org/docs/handbook/utility-types.h... [2] https://www.typescriptlang.org/docs/handbook/utility-types.h...

Yeah, now that you mention it, I remember using it a lot when I worked more in that language.

Re: Python type hints may not be not for me in practice

#199

Post by thatcks »

aSanchezStern wrote: post #47

The thing that the author says they would prefer is already in Python, it's called NewType ( https://docs.python.org/3/library/typing.html#typing.NewType ) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation w…

mypy sadly doesn't accept 'NewType('MyType', Any)'; it complains 'error: Argument 2 to NewType(...) must be subclassable (got "Any") [valid-newtype]'. Possibly this is allowed by other Python type checkers. It is accepted at runtime, and I wish mypy allowed Any as a specific exemption to its checks.

(I'm the author of the linked-to article.)

Re: Python type hints may not be not for me in practice

#200

Post by maxbond »

maleldil wrote: post #181
throwaway2037 wrote: post #121

Earlier quoted context omitted.

You can use: > @dataclass(frozen=True) to create an immutable data class.

While that works (and I use it extensively), it's a bit hacky. You have to use `object.__setattr__` to set attributes in `__init__` or `__post_init__`, which looks so wrong.

I think the cleaner alternative would be to use a static or class method as an alternative constructor and use the init the dataclass decorator provides for you. Eg something like:

    @dataclass(frozen=True)
    class Foo:
        bar: int
        baz: str

        @classmethod
        def new(cls, bar: int) -> "Foo":
            baz = calculate_baz(bar)
            return cls(bar, baz)

    foo = Foo.new(10)
Post reply on HN