Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The different uses of Python type hints

lukeplant.me.uk

Post reply on HN
Print view View original

61–70 of 70 posts

Re: The different uses of Python type hints

#61

Post by still_grokking »

xarope wrote: post #28
Animats wrote: post #3

This sort of thing is why I gave up Python. I could see having strong typing. Or optional strong typing. But unchecked type hints are just silly. The way everybody else seems to be going is strong typing at function interfaces, with automatic inference of as much else as can be done easily. C++ (since "auto"), Go, Rust, etc.

With python you can have your cake and it eat it, though. Mock up something fast, no type hints. Now, take that POC and make it production ready, by using mypy and pydantic.

> Now, take that POC and make it production ready, by using mypy and pydantic.

Than watch it exploding in production because your "type system" is incomplete and unsound.

In my opinion an unsound static type-system is worse than no static type-system at all. In both cases you need to check everything manually. But without such pseudo type-checking you at least don't get lulled into a false sense of security.

Re: The different uses of Python type hints

#62

Post by ElectricalUnion »

aldanor wrote: post #54
atorodius wrote: post #51

Earlier quoted context omitted.

IMO type hints are mostyl about (significantly!) improving readability.

Also about improving editor experience and having better auto-completion that's based on type hints.

PyCharm and VSCode can do a lot of reasonably smart refactorings when the code isn't just a pile of `typing.Any` and that's a huge quality of life for any non trivial code base.

Re: The different uses of Python type hints

#63

Post by jessekv »

IshKebab wrote: post #58
lmeyerov wrote: post #47

For a bit of a quantitative analysis on this, we had fun doing surveying programmers here, see Table 7 @ https://lmeyerov.github.io/projects/socioplt/papers/oopsla20... Ex: Programmers value types much more for documentation vs preventing bugs. I had not expected that answer!

Yeah I've found when trying (and failing mostly) to convince Python developers to use type hints that they often think it's only to fix bugs and then resist because a) of course their code doesn't have bugs, and b) they've already written their code and discovered lots of bugs painfully at runtime, so they wouldn't get most of the bug-finding benefits anyway. They never appreciate that type hints make code easier to…

Haha I was one of those vim users. Lately I've found sublime text with pyright is an effective setup for python development.

Electon-based IDE seem to require constant access to a power outlet, at least on my laptop.

Re: The different uses of Python type hints

#64

Post by still_grokking »

jessekv wrote: post #63
IshKebab wrote: post #58

Earlier quoted context omitted.

Yeah I've found when trying (and failing mostly) to convince Python developers to use type hints that they often think it's only to fix bugs and then resist because a) of course their code doesn't have bugs, and b) they've already written their code and discovered lots of bugs painfully at runtime, so they wouldn't get most of the bug-finding benefits anyway. They never appreciate that type hints make code easier to…

Haha I was one of those vim users. Lately I've found sublime text with pyright is an effective setup for python development. Electon-based IDE seem to require constant access to a power outlet, at least on my laptop.

Honest question: Are you coding in a tent, outside of civilization?

I've never understood this "battery argument".

Re: The different uses of Python type hints

#65

Post by gdprrrr »

Epa095 wrote: post #44
abraxas wrote: post #7

The issue that I have with Python type hints is they they don't go nearly far enough in describing the data being manipulated. Specifically, I'm thinking of stuff like the dimensionality and cardinality of Numpy arrays or Pandas frames. Usually that's the stuff where I have most questions when I look at Python code and the type system as it's being used now offers no help there.

You very quickly get undecidable type checking with such a powerful typesystem. Then you need a way to handle that, usually the solution is to help the type checker along by providing a proof that your code inhabits the claimed type. Then you need a way to have the proof live together with the code, a proof language, and preferably a whole library of proofs people can build on. If this sounds fun then you can go play…

C++, Java and Rust seem to do well with undecidable type checking.

Re: The different uses of Python type hints

#66

Post by MrJohz »

t43562 wrote: post #46

I inherited a python based build system which had been written without any unit tests because....it's a build system right? right?? Anyhow it was the kind of thing where you'd build for 20 minutes (Android) and then have some kind of trivial error in the python code at the end of the build. You fix that and run again and waste another 20 minutes on the next thing. I couldn't do unit tests all at once because of the d…

Again, purely anecdotally, I've done similar things in both Typescript and Python, and I usually catch at least one silly type error in Typescript, but I rarely do in Python. That could be because the Python developers I was following were just so good, but I suspect it's more about the quality of the typecheckers. Typescript feels much better at finding errors in normal, idiomatic Javascript, whereas I feel that with Mypy, if I want the best results, I need to write code in a way that plays to its strengths.

I've been told that Pyright is better but I've not tried it out properly. But yeah, your experience largely matches with mine, for Python at least.

Re: The different uses of Python type hints

#67

Post by Heston »

dragonwriter wrote: post #19
Heston wrote: post #5

The only reason to consider type hints is for a performance increase and there wasn't any mention of that. What can you really expect from using type hints accurately?

> The only reason to consider type hints is for a performance increase No, the reason to consider type hints is because it makes it easier to understand existing code and write new code that interacts with it correctly. Comprehensibility and correctness are more important than performace.

In a dynamically typed language, that's what comments are for. Since you didn't need types specified in the first place, why would you have trouble interacting with it? Comprehensibility and correctness are just as important as performance.

Re: The different uses of Python type hints

#68

Post by jessekv »

still_grokking wrote: post #64
jessekv wrote: post #63

Earlier quoted context omitted.

Haha I was one of those vim users. Lately I've found sublime text with pyright is an effective setup for python development. Electon-based IDE seem to require constant access to a power outlet, at least on my laptop.

Honest question: Are you coding in a tent, outside of civilization? I've never understood this "battery argument".

Not sure its an honest question. But sometimes I work on the train. Or in the cute coffee place down the street.

Re: The different uses of Python type hints

#69

Post by still_grokking »

jessekv wrote: post #68
still_grokking wrote: post #64

Earlier quoted context omitted.

Honest question: Are you coding in a tent, outside of civilization? I've never understood this "battery argument".

Not sure its an honest question. But sometimes I work on the train. Or in the cute coffee place down the street.

It was a honest question. (But got down-voted nevertheless… :-))

I'm not a fan of Electon-based "apps" either, as they're very problematic in all kinds of ways.

But I never could, and still can't, understand the "battery argument".

Battery life is not the biggest issue with Electon (and actually IntelliJ is even a greater power sucker).

The point is: Most people doing software development never "work" anywhere where there's no power outlet!

Most modern trains have power outlets. Likely every coffee place in the western world has power outlets.

If you're not an a safari, or in the forests, or desert there always will be a power outlet near you.

So the whole premise of "I need 10h of battery life" is moot. You actually never need that!

Even if you work sometimes on the go the battery needs only to last as long as you're moving form power outlet to power outlet.

Everything else boils down to: People these days are even too lazy plug in a charger…

Re: The different uses of Python type hints

#70

Post by jessekv »

still_grokking wrote: post #69
jessekv wrote: post #68

Earlier quoted context omitted.

Not sure its an honest question. But sometimes I work on the train. Or in the cute coffee place down the street.

It was a honest question. (But got down-voted nevertheless… :-)) I'm not a fan of Electon-based "apps" either, as they're very problematic in all kinds of ways . But I never could, and still can't, understand the "battery argument". Battery life is not the biggest issue with Electon (and actually IntelliJ is even a greater power sucker). The point is: Most people doing software development never "work" anywhere where…

Haha you are right that I typically am working within 30 feet of an outlet. But not usually seated within 6 feet of an outlet.

Maybe we can invent wireless power to go along with the wireless ethernet?

Personally I would prefer to just use less power. Chips have never been more efficient, and batteries have never been bigger. With the right software, even an older laptop can last all day.

Post reply on HN