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

121–130 of 209 posts

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

#121

Post by throwaway2037 »

ansgri wrote: post #60
rcfox wrote: post #58

Earlier quoted context omitted.

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.

You can use:

    > @dataclass(frozen=True)
to create an immutable data class.

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

#122

Post by Der_Einzige »

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…

Why is it that many of the examples for the "typing.protocal" class right below this involve meth??? Python WTF?

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

#123

Post by rnewme »

Der_Einzige wrote: post #122
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…

Why is it that many of the examples for the "typing.protocal" class right below this involve meth??? Python WTF?

method? Or are you being sarcastic?

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

#124

Post by linsomniac »

Similar to the author, I infrequently write Python code (though I have a long history with it), but I feel quite the opposite about type hints. A few specific comments:

- The LLMs can really help with typing tricky situations. If your editor can't already tell you what to use, asking an LLM usually can give me the answer.

- Type annotations for code that might change is a lifesaver, because when I change it later on I now get a bunch of conflicts where I've used it using the old way.

- Feel free to add annotations where it makes sense and is easy, and if something doesn't make sense or it is too hard to figure out the right type, you can skip it and still gain the benefits of using it elsewhere.

- Annotations don't "force you to think about types", you already are thinking about types. They let you think a bit less about types I would argue, because they're documented in function calls and returns. "Can I read() from input_file, or do I need to open()read()?" "input_file:Path" makes it better documented, without encoding the object type in the name.

I'm coming up on 30 years of using Python, and I never really missed typing, but honestly I write basically all of my new code with annotations because of the IDE benefits I get from it. I love that the Python implementation allows me to get the benefits without forcing it on me. In my distant past I very much loved coding in C, but was quite happy with Python's lack of strict typing. This feels like a good middle-ground.

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

#125

Post by throwaway2037 »

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…

    > I think that type hint are making python source code messy and unreadable.
I hear this sentiment a lot from people who rarely use strict(er) typed languages: Rust, C++, Java, C#, Go, etc. Can you imagine a developer in any of those languages complaining that "oh, now the code is messy and unreadable because we added explicit types"? It seems bizarre to think about it. Sure, Java and C# is a bit repetitive, but at least you always know the type.

There is an ongoing debate in C++, Java, and C# if the newish keyword "auto"/"var" is a good idea to hide local variable explicit types. The real issue: For the person who wrote the code, they already know the implicit types.. However, for people reading the code, they have a harder time to understand the implicit types.

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

#126

Post by Chris_Newton »

maleldil wrote: post #88
junyjujfjf wrote: post #82

Earlier quoted context omitted.

> The Python type system is pretty bad Coming from the perspective of a religious python hater, their type hints are better than what you give credit for: Supports generics, nominative, structural, unions, bottom type, and literals. What is missing is mainstream adoption in libraries which is a matter of time.

> 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 Python type hints are concerned, yet the results of an actual database query should never have a null value there. Guarding against None every time you refer to one of them is tedious.

I’m not exactly the world’s loudest advocate for ORMs anyway, but on projects that also try to take type safety seriously, they do seem to be a bit of a dark corner within the Python ecosystem.

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

#127

Post by pansa2 »

throwaway2037 wrote: post #125
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…

> I think that type hint are making python source code messy and unreadable. I hear this sentiment a lot from people who rarely use strict(er) typed languages: Rust, C++, Java, C#, Go, etc. Can you imagine a developer in any of those languages complaining that "oh, now the code is messy and unreadable because we added explicit types"? It seems bizarre to think about it. Sure, Java and C# is a bit repetitive, but at l…

> Can you imagine a developer in any of those languages complaining that "oh, now the code is messy and unreadable because we added explicit types"?

Python used to be described as "executable pseudocode". None of the languages you've listed have ever been considered that easy to read.

Making Python look more like them is therefore a step backwards in terms of cleanliness and readability.

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

#129

Post by dikei »

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://…

That code looks like a proper object-oriented design to me, nothing to do with type-hints actually.

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

#130

Post by sethammons »

hbrn wrote: post #63
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).

> Writing software without types lets you go at full speed. Full speed towards the cliff. Isn't it strange that back when Python (or Ruby) didn't even have type hints (not type checkers, type hints!), it would easily outperform pretty much every heavily typed language? Somehow when types weren't an option we weren't going towards the cliff, but now that they are, not using them means jumping off a cliff? Something do…

Every single typed system I have ever worked on, no matter how poorly designed, has been easier to alter than the vast majority of ruby, python, perl, php, and elixir that I've worked on
Post reply on HN