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

541–550 of 581 posts

Re: Python developers are embracing type hints

#541

Post by bityard »

dragonwriter wrote: post #535
bityard wrote: post #418

Earlier quoted context omitted.

"There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer. It was originally meant as a counterpoint to Perl's "there's more than one way to do it," to show that the Python developers put a priority on quality and depth of features rather than quantity. But times change and these days, Python is a much larger language with a bigger community, and there is a l…

> "There should only be one way to do it" has not really been a thing in Python for at least the last decade or longer. It never was a thing in Python, it is a misquote of the Zen of Python that apparently became popular as a reaction against the TMTOWTDI motto of the Perl community.

Not misquoted, paraphrased. I didn't feel like bothering to check the output of "import this" before posting.

Re: Python developers are embracing type hints

#542

Post by mixmastamyk »

hnlmorg wrote: post #344
pydry wrote: post #138

Earlier quoted context omitted.

Here we are because: * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. * Types are incredibly valuable on hardened production code. * Most good production code started out spikey, experimental or as an MVP and transitioned . And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has…

> Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. I find I’ve spent so much time writing with typed code that I now find it harder to write POC code in dynamic languages because I use types to help reason about how I want to architect something. Eg “this function should calculate x and return”, well if you already know what you want the function to do then…

Python doesn’t have “no types,” in fact it is strict about types. You just don’t have to waste time reading and writing them early on.

While a boon during prototyping, a project may need more structural support as the design solidifies, it grows, or a varied, growing team takes responsibility.

At some point those factors dominate, to the extent “may need” support approaches “must have.”

Re: Python developers are embracing type hints

#543

Post by letmeinhere »

Narushia wrote: post #393
rgovostes wrote: post #93

Earlier quoted context omitted.

I am glad they improved this but I still like Optional[], and to a lesser extent, Union[]. It's much more readable to have Optional[str] compared to str | None.

I disagree with `Optional`. It can cause confusion in function signatures, since an argument typed as "optional" might still be required if there is no default value. Basically I think the name is bad, it should be `Nullable` or something. I believe Python's own documentation also recommends the shorthand syntax over `Union`. Linters like Pylint and Ruff also warn if you use the imported `Union`/`Optional` types. The…

Option is a pretty common name for this, as is Maybe.[^1] Either way I think that ship is sailed in Python.

[^1]: https://en.wikipedia.org/wiki/Option_type

Re: Python developers are embracing type hints

#544

Post by letmeinhere »

lexicality wrote: post #452
maleldil wrote: post #46

Earlier quoted context omitted.

> 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

Exactly, I want it to complain if I try to manipulate the fields/methods of an unknown object.

Re: Python developers are embracing type hints

#545

Post by mixmastamyk »

dahauns wrote: post #407
Mond_ wrote: post #211

Earlier quoted context omitted.

> * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. This is what people say, but I don't think it's correct. What is correct is that say, ten to twenty years ago, all the statically typed languages had other unacceptable drawbacks and "types bad" became a shorthand for these issues. I'm talking about C (nonstarter for obvious reasons), C++ (a huge mess, fo…

I think Java was the main one. C/C++ are (relatively) close to the metal, system-level languages with explicit memory management - and were tacitly accepted to be the "complicated" ones, with dynamic typing not really applicable at that level. But Java was the high-level, GCed, application development language - and more importantly, it was the one dominating many university CS studies as an education language before…

For me it was more the “java can’t easily process strings” craze that made it impractical to use for scripts or small to medium projects.

Not to mention boilerplate BS.

Recently, Java has improved a lot on these fronts. Too bad it’s twenty-five years late.

Re: Python developers are embracing type hints

#546

Post by mixmastamyk »

cyberax wrote: post #184
pydry wrote: post #138

Earlier quoted context omitted.

Here we are because: * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. * Types are incredibly valuable on hardened production code. * Most good production code started out spikey, experimental or as an MVP and transitioned . And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has…

> * Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. Press "X" to doubt. Types help _a_ _lot_ by providing autocomplete, inspections, and helping with finding errors while you're typing. This significantly improves the iteration speed, as you don't need to run the code to detect that you mistyped a varible somewhere.

Pycharm, pyflakes, et all can do most of these without written types.

The more interesting questions, like “should I use itertools or collections?” Autocomplete can’t help with.

Re: Python developers are embracing type hints

#547

Post by mixmastamyk »

lelanthran wrote: post #161
flohofwoe wrote: post #130

Earlier quoted context omitted.

OTH I only came to realize that I actually like duck typing in some situations when I tried to add type hints to one of my Python projects (and then removed them again because the actually important types consisted almost entirely of sum types, and what's the point of static typing if anything is a variant anyway). E.g. when Python is used as a 'scripting language' instead of a 'programming language' (like for writin…

> Because tbh, even with type hints Python is a lousy programming language (but a fine scripting language). I'd be interested in seeing you expand on this, explaining the ways you feel Python doesn't make the cut for programming language while doing so for scripting. The reason I say this is because, intuitively, I've felt this way for quite some time but I am unable to properly articulate why, other than "I don't wa…

Learn how to use the tools to prevent that last paragraph.

Re: Python developers are embracing type hints

#548

Post by mixmastamyk »

procaryote wrote: post #274
jmorenoamor wrote: post #157

Earlier quoted context omitted.

Coming from Java extreme verbosity, I just loved the freedom of python 20 years ago. Working with complex structures with mixed types was a breeze. Yes, it was your responsibility to keep track of correctness, but that also taught me to write better code, and better tests.

Writing tests is harder work than writing the equvalent number of type hints though

Hints are not sufficient, you’ll need tests anyway. They somewhat overlap.

Re: Python developers are embracing type hints

#549

Post by hnlmorg »

mixmastamyk wrote: post #542
hnlmorg wrote: post #344

Earlier quoted context omitted.

> Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away. I find I’ve spent so much time writing with typed code that I now find it harder to write POC code in dynamic languages because I use types to help reason about how I want to architect something. Eg “this function should calculate x and return”, well if you already know what you want the function to do then…

Python doesn’t have “no types,” in fact it is strict about types. You just don’t have to waste time reading and writing them early on. While a boon during prototyping, a project may need more structural support as the design solidifies, it grows, or a varied, growing team takes responsibility. At some point those factors dominate, to the extent “may need” support approaches “must have.”

My point is if you don’t know what types you need, then you can’t be trusted to write the function to begin with. So you don’t actually save that much time in the end. typing out type names simply isn’t the time consuming part of prototyping.

But when it comes to refactoring, having type safety makes it very easy to use static analysis (typically the compiler) check for type-related bugs during that refactor.

I’ve spent a fair amount of years in a great many different PL paradigms and I’ve honestly never found loosely typed languages any fast for prototyping.

That all said, I will say that a lot of this also comes down to what you’re used to. If you’re used to thinking about data structures then your mind will go straight there when prototyping. If you’re not used to strictly typed languages, then you’ll find it a distraction.

Re: Python developers are embracing type hints

#550

Post by sota_pop »

marcosdumay wrote: post #441
sota_pop wrote: post #317

Python types - all the onus of static types, with none of the performance! I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props. Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type…

> with none of the performance! If you care about micro-optimizations, the first one that overwhelms everything else is to not use Python. Anyway, if your types are onerous, you are using them wrong. Even more in a progressive type system where you always have the option of not using them or putting an "Any" there.

While most responders seem to have latched on to the pedantics of my “oop” comment - this is what my comment was intended to imply: why force the verbosity of static types on Python when statically typed (sic compiled) languages typically have much better runtime performance? the real answer i suspect is for quality of life/readability of code, but they are just “hints” afterall.
Post reply on HN