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

451–460 of 581 posts

Re: Python developers are embracing type hints

#451

Post by lexicality »

pansa2 wrote: post #241
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

on that note, which is better, using `map()` or a generator expression?

Re: Python developers are embracing type hints

#452

Post by lexicality »

maleldil wrote: post #46
letmeinhere wrote: post #31

Earlier quoted context omitted.

Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...

> hoping for an Unknown someday Wouldn't that just be `object` in Python?

No, because the type checker should prevent you interacting with `Unknown` until you tie it down, but `object` is technically a valid type

Re: Python developers are embracing type hints

#453

Post by rao-v »

I’d love to see an analysis of how much typing hurts LLMs that need to read / edit your code (due to increased context) vs helps (due to more clear type context).

I want to believe that corrected typed python code is easier for smaller models to generate / interact with, but who knows how the trade-offs actually work out.

Re: Python developers are embracing type hints

#454

Post by mjr00 »

pdonis wrote: post #399
mjr00 wrote: post #74

Earlier quoted context omitted.

> The desired type is known; it's "Addable" (i.e., "doesn't throw an exception when the built-in add operator is used"). The mistake both you and the reddit posts' author make is treating the `+` operator the same as you would an interface method. Despite Python having __add__/__radd__ methods, this isn't true, nor is it true in many other programming languages. For example, Go doesn't have a way to express "can use…

> treating the `+` operator the same as you would an interface method In other words, you agree that the Python type hint system does not give you a good, built-in way to express the "Addable" type. Which means you are contradicting your claims that the type the article wants to express is "unknown" and that the article is advocating using "Any" for this case. The type is not unknown--it's exactly what I said: "doesn…

> I don't see why. Addition is a very commonly used operation, and being able to have a type system that can express "this function takes two arguments that can be added using the addition operator" seems like something any type system that delivers the goods it claims to deliver ought to have.

If your comparison is Rust, sure, but you can't even express this in Java. No, Java's type system is not great, but it's a type system that's been used for approximately 500 trillion lines of production code powering critical systems and nobody has ever said "Java sucks because I can't express 'supports the + operator' as a generic type". (It sucks for many other reasons.)

Again, it is factually and objectively an esoteric and unusual case. Nobody in the real world is writing generics like this, only academics or people writing programming blogs about esoterica.

If your argument is that all type systems are bad or deficient, fine, but calling out Python for this when it has the exact same deficiency as basically every other mainstream language is asinine.

> The article never says that either. You are attacking straw men.

The article says "Turning even the simplest function that relied on Duck Typing into a Type Hinted function that is useful can be painfully difficult." The subterfuge is that this is not even remotely close to a simple function because the type being expressed, "supports the + operator", is not even remotely close to a simple type.

Re: Python developers are embracing type hints

#455

Post by xzel »

pansa2 wrote: post #241
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

And Python failed at that decades ago. People push terribly complicated, unreadable code under the guise of Pythonic. I disagree with using Pythonic as reasoning for anything.

Re: Python developers are embracing type hints

#456

Post by xzel »

pansa2 wrote: post #241
kketch wrote: post #237

Earlier quoted context omitted.

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime. Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

> They don’t violate the spirit of the language. They are optional. That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

And Python failed at that decades ago. People push terribly complicated, unreadable code under the guise of Pythonic. I disagree with using Pythonic as reasoning for anything.

Re: Python developers are embracing type hints

#457

Post by actinium226 »

AlienRobot wrote: post #49
tecoholic wrote: post #35

I love typing in Python. I learnt programming with C++ and OOPs. It was freeing when I took up Python to note care about types, but I have come to enjoy types as I got older. But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. The pain is code examples of the libraries don’t even show t…

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…

> If you have a cyclic reference between two files,

Don't have cyclic references between two files.

It makes testing very difficult, because in order to test something in one file, you need to import the other one, even though it has nothing to do with the test.

It makes the code more difficult to read, because you're importing these two files in places where you only need one of them, and it's not immediately clear why you're importing the second one. And it's not very satisfying to learn that you you're importing the second one not because you "need" it but because the circular import forces you to do so.

Every single time you have cyclic references, what you really have are two pieces of code that rely on a third piece of code, so take that third piece, separate it out, and have the first two pieces of code depend on the third piece.

Now things can be tested, imports can be made sanely, and life is much better.

Re: Python developers are embracing type hints

#458

Post by AlienRobot »

actinium226 wrote: post #457
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…

> If you have a cyclic reference between two files, Don't have cyclic references between two files. It makes testing very difficult, because in order to test something in one file, you need to import the other one, even though it has nothing to do with the test. It makes the code more difficult to read, because you're importing these two files in places where you only need one of them, and it's not immediately clear…

Using the typical "Rust-killer" example: if you have a linked list where the List in list.py returns a Node type and Node in node.py takes a List in its constructor, you already have a cyclic reference.

Re: Python developers are embracing type hints

#459

Post by procaryote »

moefh wrote: post #254
ktosobcy wrote: post #246

Earlier quoted context omitted.

Well, we do coalesce on certain things... some static type languages are dropping type requirements (Java and `var` in certain places) :D

There's no dropping of type requirements in Java, `var` only saves typing. When you use `var`, everything is as statically typed as before, you just don't need to spell out the type when the compiler can infer it. So you can't (for example) say `var x = null` because `null` doesn't provide enough type information for the compiler to infer what's the type of `x`.

> `var` only saves typing.

this is a lovely double entendre

Re: Python developers are embracing type hints

#460

Post by AlienRobot »

ninetyninenine wrote: post #88
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…

You're actually missing the benefit of this. It's actually a feature. With python, because types are part of python itself, they can thus be programmable. You can create a function that takes in a typehint and returns a new typehint. This is legal python. For example below I create a function that dynamically returns a type that restricts a Dictionary to have a specific key and value. from typing import TypedDict def…

That's horrible. Nobody needs imperative metaprogramming for type hints. In fact, it would be absolute insanity for a typechecker to check this because it would mean opening a file in VS code = executing arbitrary python code. What stops me from deleting $HOME inside make_typed_dict?

TypeScript solves this with its own syntax that never gets executed by an interpreter because types are striped when TS is compiled to JS.

Post reply on HN