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

111–120 of 581 posts

Re: Python developers are embracing type hints

#111

Post by pcwelder »

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…

It doesn't throw error in the REPL though. Surely you meant to share some other example?

Re: Python developers are embracing type hints

#112

Post by ninetyninenine »

JimDabell wrote: post #102
ninetyninenine wrote: post #84

Earlier quoted context omitted.

This is a naive realization. When type checking is used to the maximum extent they become as just as important as unit testing. It is an actual safety contribution to the code. Many old school python developers don't realize how important typing actually is. It's not just documentation. It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.

> It can actually roughly reduce dev time by 50% and increase safety by roughly 2x. Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario…

>Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there?

My own anecdotal metric. Isn't that obvious? The initial post was an anecdotal opinion as well. I don't see a problem here.

>In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario, but NoneType gets everywhere if you let it.

It's not just None. Imagine some highly complex object with nested values and you have some function like this:

   def modify_direction(direction_object) -> ...
wtf is direction object? Is it in Cartesian or is it in polar? Is in 2D or 3D? Most old school python devs literally have to find where modify_direction is called and they find this:

   def modify_data(data) -> ...
       ...
       modify_direction(data.quat)
Ok then you have to find where modify data is called, and so on and so forth until you get to here:

   def combind_data(quat) -> ...

   def create_quat() -> quat
And then boom you figure out what it does by actually reading all the complex quaternion math create_quat does.

Absolutely insane. If I have a type, I can just look at the type to figure everything out... you can see how much faster it is.

Oh and get this. Let's say there's someone who feels euler angles are better. So he changes create_quat to create_euler. He modifies all the places create_quat is used (which is about 40 places) and he misses 3 or 4 places where it's called.

He then ships it to production. Boom The extra time debugging production when it crashes, ans also extra time tediously finding where create_quat was used. All of that could have been saved by a type checker.

I'm a big python guy. But I'm also big into haskell. So I know both the typing worlds and the untyped worlds really well. Most people who complain like you literally have mostly come from a python background where typing isn't used much. Maybe you used types occasionally but not in a big way.

If you used both untyped languages and typed languages extensively you will know that types are intrinsically better. It's not even a contest. Anyone who still debates this stuff just lacks experience.

Re: Python developers are embracing type hints

#113

Post by Too »

raincole wrote: post #101
ninetyninenine wrote: post #82

Earlier quoted context omitted.

I learned C++ before learning python as well and python felt like a breath of fresh air. At first I thought it was because of the lack of types. But in actuality the lack of types was a detriment for python. It was an illusion. The reason why python felt so much better was because it had clear error messages and a clear path to find errors and bugs. In C++ memory leaks and seg faults are always hidden from view so EV…

> It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++. It's an illusion only you once had. Java (a language that is not C or C++) got mainstream way before Python.

Java on the other hand had the most verbose syntax known to man, especially those early versions of it. Nowadays it’s getting more tolerable.

Re: Python developers are embracing type hints

#115

Post by watwut »

MangoToupe wrote: post #94
ninetyninenine wrote: post #84

Earlier quoted context omitted.

This is a naive realization. When type checking is used to the maximum extent they become as just as important as unit testing. It is an actual safety contribution to the code. Many old school python developers don't realize how important typing actually is. It's not just documentation. It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.

Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, even if the end-goal is to ship an api with clear type signatures. There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. > Many old school python d…

> Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development,

No they dont. There is nothing about types that would make incremental develpment harder. They keep having the same benefits when being incremental.

Re: Python developers are embracing type hints

#116

Post by Too »

zoom6628 wrote: post #103

Boring old me would be reaching for mojo in order to have types that actually are "real" rather than just an editing overlay of decorators/DSL/tooling.

Too bad Mojo gave up on Python compatibility on code level. Now it’s just one of a dozen “Python inspired” languages, with the only benefit that they aim for easily calling into other Python code.

Re: Python developers are embracing type hints

#117

Post by jgb1984 »

iandanforth wrote: post #45

I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams. Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As lon…

Couldn't agree more! I've been using Python for almost 20 years, my whole career is built on it, and I never missed typing. Code with type hints is so verbose and unpythonic, making it much harder to read. Quite an annoying evolution.

Re: Python developers are embracing type hints

#118

Post by adalacelove »

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.

People adapt to the circumstances. A lot of Python uses are no longer about fast iteration on the REPL. Instead of that we are shipping Python to execute in clusters on very long running jobs or inside servers. It's not only about having to start all over after hours, it's simply that concurrent and distributed execution environments are hostile to interactive programming. Now you can't afford to wait for an exception and launch the debugger in postmortem. Or even if you do it's not very useful.

And now my personal opinion: If we are going the static typing way I would prefer simply to use Scala or similar instead of Python with types. Unfortunately in the same way that high performance languages like C attracts premature optimizers static types attract premature "abstracters" (C++ both). I also think that dynamic languages have the largest libraries for technical merit reasons. Being more "fluid" make them easier to mix. In the long term the ecosystem converges organically on certain interfaces between libraries.

And so here we are with the half baked approach of gradual typing and #type: ignore everywhere.

Re: Python developers are embracing type hints

#119

Post by aurareturn »

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.

Javascript is no longer was just scripting. Very large and complex billion dollar apps were being written in pure Javascript. It grew up.

I guess Python is next.

Re: Python developers are embracing type hints

#120

Post by _flux »

Too wrote: post #106
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…

This is trivial to solve by simply not having circular imports. Place the types in one file and the usage of it in others. This has many benefits, like forcing you to think about the dependencies and layers of your architecture. Here is a good read about why, from F# that has the same limitation https://fsharpforfunandprofit.com/posts/cyclic-dependencies/ As others already mentioned, importing __annotations__ also wo…

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 while the issue can be worked around, it still seemed to creep up at times. Rust, also with some virtual OCaml ancestry, went completely the opposite way.

My view is that while in principle it's a nice property that you can read and and understand a piece of code by starting from the top and going to the bottom (and a REPL is going to do exactly that), in practice it's not the ultimate nice property to uphold.

Post reply on HN