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

51–60 of 209 posts

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

#51

Post by ratmeadow »

wenc wrote: post #39
greatgib wrote: post #8

The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. I'm missing a lot simple functions with explicit argument names and docstrings with arguments types and descriptions clearly but discreetly documented. It was one big strength of Python to have so simple and clean code without too much boilerplate. Also, I have the feeling that static typing extremis…

> The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. Compared to legacy Python, yes. Compared to verbose language like Java, no. Python typing is equal or less verbose than Java (unless you use "var" in Java).

Python people legitimately upset they can't write every function like this now:

def func(data, *kwargs): """data: the data. kwargs: other data."""

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

#52

Post by teddyh »

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…

Take care to differentiate strong/weak typing from dynamic/static typing. Many dynamically typed languages (especially older ones) are also weakly typed, but some dynamic langugages, like Python, are strongly typed. 1 + "2" == 12 is weak typing, and Python has strong typing. Type declarations are static typing, in contrast to traditional Python, which had (and still has) dynamic typing.

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

#53

Post by alfons_foobar »

colemannerd wrote: post #50
Myrmornis wrote: post #29

Earlier quoted context omitted.

Can you give some examples of how the Python type system is disappointing you?

default values! Since type hints are *hints*, it is difficult to set default values for complicated types. For instance, if you have lists, dicts, sets in the type signature, without a library like pydantic, it is difficult and non-standard. This becomes even more problematic when you start doing more complicated data structures. The configuration in this library starts to show the problems. https://koxudaxi.github.i…

I might be dense, but I don't understand what that has to do with type hints...

To my eyes, the problem of choosing useful defaults for complicated types/datastructures is independent of whether I add type hints for them.

I think I am missing something...

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

#54

Post by CJefferson »

Myrmornis wrote: post #29
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).

Can you give some examples of how the Python type system is disappointing you?

Mainly, the seems to be no way, in a dynamic language, to dynamically check if functions get the right types.

To me, this means I don't really understand the python type hinting at all, as adding hints to just one or two functions provides no value to me at all.

I assume I must be not using them usefully, as I've tried adding type hints to some projects and they just seemed to do nothing useful.

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

#55

Post by Spivak »

CJefferson wrote: post #54
Myrmornis wrote: post #29

Earlier quoted context omitted.

Can you give some examples of how the Python type system is disappointing you?

Mainly, the seems to be no way, in a dynamic language, to dynamically check if functions get the right types. To me, this means I don't really understand the python type hinting at all, as adding hints to just one or two functions provides no value to me at all. I assume I must be not using them usefully, as I've tried adding type hints to some projects and they just seemed to do nothing useful.

Type hints alone don't do this, but you can use Pydantic to accomplish what you want. In Python type hints aren't enforced anywhere at runtime. They're for a type-checker to validate your source.

https://docs.pydantic.dev/latest/concepts/validation_decorat...

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

#56

Post by stoperaticless »

scoofy wrote: post #43

My objection to strong types in python is philosophical. Python mimics natural language, and natural language rejects strong types for context resolved ambiguity. In the way we resolve these issues in natural language, we can resolve bugs in python, that is, “do you mean integer ’3’ or string’3’” instead of insisting we define everything always forever. To me, people who use type hinting are just letting me know they…

Strong/weak types and static/dynamic typing are orthogonal things.

Strong type system limits things like 1+”1”.

Static type system requires type declarations (“int i”).

Python always had strong dynamic types.

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

#57

Post by solidsnack9000 »

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.

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

#58

Post by rcfox »

ansgri wrote: post #40
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).

If it’s 100x better than no types, then probably 10x better than C++ type system. It takes some time to unlearn using dicts everywhere, but then namedtuples become your best friend and noticeably improve maintainability. Probably the only place where python type system feels inadequate is describing json-like data near the point of its (de)serialization.

Pretty much anywhere you're tempted to use a namedtuple, you should be using a dataclass[0] instead.

And typing JSON-like data is possible with TypedDict[1].

[0] https://docs.python.org/3/library/dataclasses.html

[1] https://docs.python.org/3/library/typing.html#typing.TypedDi...

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

#59

Post by tecoholic »

ansgri wrote: post #40
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).

If it’s 100x better than no types, then probably 10x better than C++ type system. It takes some time to unlearn using dicts everywhere, but then namedtuples become your best friend and noticeably improve maintainability. Probably the only place where python type system feels inadequate is describing json-like data near the point of its (de)serialization.

There’s TyepdDict that is decent for a JSON like data structure if the types are simple. It doesn’t have the bells and whistles of Pydantic, but gets the job done for passing predictable dicts around and ensuring consistency while developing

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

#60

Post by ansgri »

rcfox wrote: post #58
ansgri wrote: post #40

Earlier quoted context omitted.

If it’s 100x better than no types, then probably 10x better than C++ type system. It takes some time to unlearn using dicts everywhere, but then namedtuples become your best friend and noticeably improve maintainability. Probably the only place where python type system feels inadequate is describing json-like data near the point of its (de)serialization.

Pretty much anywhere you're tempted to use a namedtuple, you should be using a dataclass[0] instead. And typing JSON-like data is possible with TypedDict[1]. [0] https://docs.python.org/3/library/dataclasses.html [1] https://docs.python.org/3/library/typing.html#typing.TypedDi...

Why? I thought one should prefer immutability. As for typed dicts.. yes, I’m mostly stuck on old python versions, nice reminder.
Post reply on HN