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

251–260 of 581 posts

Re: Python developers are embracing type hints

#251

Post by _flux »

Too wrote: post #218
_flux wrote: post #120

Earlier quoted context omitted.

If the type is a class with methods, then this method doesn't work, though adding intermediate interface classes (possibly with Generic types) might help in most cases. Python static type system isn't quite the same level as F#. > Well, these complaints are unfounded. "You're holding it wrong." I've also coded quite a bit of OCaml and it had the same limitation (which is where F# picked it up in the first place), and…

> If the type is a class with methods, then this method doesn't work Use typing.Self

I meant if you have two classes that need to refer to each other. But good pointer anyway, I hadn't noticed it, thanks!

Re: Python developers are embracing type hints

#252

Post by constantcrying »

ktosobcy wrote: post #246
seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

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

var does absolutely nothing to make Java a less strictly typed language. There is absolutely no dropping of the requirement that each variable has a type which is known at compile time.

Automatic type inference and dynamic typing are totally different things.

Re: Python developers are embracing type hints

#253

Post by tdeck »

Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

I like Python a lot, and have been using it for personal projects since about 2010. It was only once I started working and encountering long-lived unfamiliar Python codebases regularly that I understood the benefits of type hints. It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. It's even less fun to find out that someone made a mistake and it's actually two different incompatible things depending on the execution path.

That era of Python codebases were miserable to work in, and often ended up in the poorly though out "we don't know how this works and it has too many bugs, let's just rewrite it" category.

Re: Python developers are embracing type hints

#254

Post by moefh »

ktosobcy wrote: post #246
seanparsons wrote: post #110

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages. When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

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`.

Re: Python developers are embracing type hints

#255

Post by tdeck »

graynk wrote: post #242
pansa2 wrote: post #241

Earlier quoted context omitted.

> 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”.

the whole language violates this principle tbh, so it's very in spirit

Yeah that ship sailed some time before they added a third way to do templated string interpolation.

Re: Python developers are embracing type hints

#256

Post by rlpb »

tdeck wrote: post #253
Dr_Birdbrain wrote: post #215

I actually don’t like python type hints! At my work we have a jit compiler that requires type hints under some conditions. Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess. For example a common failure mode in my work’s codebase is that some func…

I like Python a lot, and have been using it for personal projects since about 2010. It was only once I started working and encountering long-lived unfamiliar Python codebases regularly that I understood the benefits of type hints. It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. It's even less fun to find out that someone ma…

> It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something.

My position is that what is intended must be made clear between type hints and the docstring. Skipping this makes for difficult to read code and has no place in a professional setting in any non-trivial codebase.

This doesn't require type hints to achieve. :param and :rtype in the docstring are fine if type hints aren't present, or for complex cases, plain English in the docstring is usually better.

Re: Python developers are embracing type hints

#257

Post by JimDabell »

ninetyninenine wrote: post #166
JimDabell wrote: post #121

Earlier quoted context omitted.

> My own anecdotal metric. Isn't that obvious? The initial post was an anecdotal opinion as well. I don't see a problem here. WTF is “an anecdotal metric”‽ That just sounds like an evasive way to say “I want to make up numbers I can’t justify” . > wtf is direction object? Is it in Cartesian or is it in polar? Is in 2D or 3D? This seems very domain-specific. > Most people who complain like you literally have mostly co…

>WTF is “an anecdotal metric”‽ That just sounds like an evasive way to say “I want to make up numbers I can’t justify”. What I have to have scientific papers for every fucking opinion I have? The initial Parent post was an anecdotal opinion. Your post is an opinion. I can't have opinions here without citing a scientific paper that's 20 pages long and no is going to read but just blindly trust because it's "science"?…

> What I have to have scientific papers for every fucking opinion I have?

No, but if you’re going to say things like “increase safety by roughly 2x” then if you can’t even identify the unit then you are misleading people.

It’s absolutely fine to have an opinion. It’s not fine to make numbers up.

> I'm confident my "anecdotal" metrics with I prefaced with "roughly" are "roughly" ballpark trueish.

Okay, so if it’s 1.5×, 2.0×, or 2.5×… again, what metric? What unit are we dealing with?

You’re claiming that it’s “in the ballpark”, but what is “in the ballpark”? The problem is not one of accuracy, the problem is that it’s made up.

> If someone disagrees with me (on this specific topic), it absolutely doesn't mean they are a junior. It means they lack knowledge and experience. This is a fact.

It’s not a fact, it’s ridiculous. You genuinely believe that if somebody disagrees with you, it’s a fact that they lack knowledge and experience? It’s not even remotely possible for somebody to have an informed difference of opinion with you?

Re: Python developers are embracing type hints

#258

Post by meander_water »

meander_water wrote: post #99
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…

There's actually another issue with ForwardRefs. They don't work in the REPL. So this will work when run as a module: def foo() -> "Bar": return Bar() But will throw an error if copy pasted into a REPL. However, all of these issues should be fixed in 3.14 with PEP649 and PEP749: > At compile time, if the definition of an object includes annotations, the Python compiler will write the expressions computing the annotat…

Please ignore my first assertion that the behavior between REPL and module is different.

This would have been the case if the semantics of the original PEP649 spec had been implemented. But instead, PEP749 ensures that it is not [0]. My bad.

[0] https://peps.python.org/pep-0749/#behavior-of-the-repl

Re: Python developers are embracing type hints

#259

Post by dotancohen »

lolive wrote: post #245
dotancohen wrote: post #134

Earlier quoted context omitted.

Then what is? Everybody knows the limitations of JSON. Don't state the obvious problem without stating a proposed solution.

The RDF structure is a graph of typed instances of typed objects, serializable as text. Exchanging RDF, more precisely its [more readable] "RDF/turtle" variant, is probably what will eventually come to the market somehow. Each object of a RDF structure has a global unique identifier, is typed, maintains typed links with other objects, have typed values.

That's a circular argument. What serialization format would you recommend? JSON?

Re: Python developers are embracing type hints

#260

Post by bc569a80a344f9c »

crabbone wrote: post #234
detaro wrote: post #220

Earlier quoted context omitted.

Can't you define your own hint for "type that has __getitem__ taking int"?

The way I understand parent is that such a type would be too broad. The bigger problem is that the type system expressed through hints in Python is not the type system Python is actually using. It's not even an approximation. You can express in the hint type system things that are nonsense in Python and write Python that is nonsense in the type system implied by hints. The type system introduced through typing packag…

> In Russian, there's an expression "like a saddle on a cow", I'm not sure what the equivalent in English would be

“To fit a square peg into a round hole”

Post reply on HN