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

Python’s “type hints” are a bit of a disappointment to me

uninformativ.de

Post reply on HN
Print view View original

461–470 of 597 posts

Re: Python’s “type hints” are a bit of a disappointment to me

#461

Post by tomerv »

wheelerof4te wrote: post #457

The main problem with type hints for Python code is that it changes the way you think about writing Python. Before, it went something like this: 1) Install Python (if you don't have it already) 2) Install your favorite text editor 3) Write some Python! Now, it goes something like this: 1) Install Python 2) Install your favorite IDE 3) Install plugins for your IDE 4) Install black, mypy, flake8 plus some other nonsens…

How did you get from type hints to black, not to mention poetry? Seems like you're just complaining about there being a mature ecosystem around Python, and the implicit expectation to use it.

Re: Python’s “type hints” are a bit of a disappointment to me

#462

Post by michaelt »

eweise wrote: post #446
jsmeaton wrote: post #239

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…

Why not just use a statically type language? I really don't understand why python is so popular outside of a few specialized areas.

Ah, but what if I'm a masochist and I want all the verbosity of a statically typed language with none of the benefits?

Re: Python’s “type hints” are a bit of a disappointment to me

#463

Post by bogwog »

jghn wrote: post #430
bayesian_horse wrote: post #290

Earlier quoted context omitted.

What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect re…

> make things possible, often just to run it once This is the largest difference. When there's no expectation of code lasting beyond a very short lifespan, why go through the effort to future proof things, improve maintainability, have better ergonomics, etc?

Because science doesn't work unless experimental results are reproducible.

Re: Python’s “type hints” are a bit of a disappointment to me

#464

Post by ImprobableTruth »

toolslive wrote: post #400
ImprobableTruth wrote: post #253

Earlier quoted context omitted.

I think I might not have been clear: this is not a limitation of the type system , but of a specific type checker (mypy), that will hopefully be fixed soon. Both Pyright and Pyre support recursive type aliases right now . Open one of their playgrounds and you'll see that the following, intuitive definition JSON = Union[ None, bool, int, float, str, List['JSON'], Dict[str, 'JSON'], ] works without issue. >In fact, you…

> JSON = Union[....] This does not define the type of a valid json object. (fe None is not a valid json object, neither is '')

A decade or so ago JSON was changed so that JSON text doesn't have to be an object, it can also be a value. 'null' (or say, '5') is therefore legal JSON.

Re: Python’s “type hints” are a bit of a disappointment to me

#465

Post by j4mie »

gilbetron wrote: post #455
j4mie wrote: post #432

Earlier quoted context omitted.

What's your definition of "large codebases" here? My experience is that on Python codebases large (~100k lines) and small, type annotations are generally a net negative, particularly with a "rotating roster of many developers", because of their complexity and detrimental effect they have on readability. As the OP says, incorrect types are worse than no types at all.

type hinting is a bandaid, I'm not going defend it. My argument is that statically typed languages are better for large scale development.

You still haven't defined "large scale" or "better". And you haven't backed up your argument with any evidence.

Re: Python’s “type hints” are a bit of a disappointment to me

#466

Post by wheelerof4te »

tomerv wrote: post #461
wheelerof4te wrote: post #457

The main problem with type hints for Python code is that it changes the way you think about writing Python. Before, it went something like this: 1) Install Python (if you don't have it already) 2) Install your favorite text editor 3) Write some Python! Now, it goes something like this: 1) Install Python 2) Install your favorite IDE 3) Install plugins for your IDE 4) Install black, mypy, flake8 plus some other nonsens…

How did you get from type hints to black, not to mention poetry? Seems like you're just complaining about there being a mature ecosystem around Python, and the implicit expectation to use it.

And here I thought my explanation at the bottom covered this.

Let's try again:

Python has become a mess. It is no longer a simple productive language to get into like it used to be. Now, you are expected to buy into it's ecosystem, like it is C# or Java.

Well, it is not. It's Python and I am truly sad they are killing it with thousand cuts.

Re: Python’s “type hints” are a bit of a disappointment to me

#467

Post by mjr00 »

ReflectedImage wrote: post #393
retrac wrote: post #33

Earlier quoted context omitted.

> useless complexity that yield little return Typechecking allows certain errors to be detected at typecheck time rather than at runtime. I don't personally consider that useless. E.g. A mistake I just made. I'm working in a language I don't know too well right now with strict static typing. The file read function takes a handle. If I pass it a string of the file name, rather than the handle result from file open, it…

The changes you need to make to a Python program to enable it to be type checked result in more bugs being added than the type checker removes leaving you at a net negative. Type checking is just a really poor way to ensure program correctness until you start using an exceptionally strongly typed language like Haskell. You use types in C / C++ / Java because the compiler needs them to work not because it's a good ide…

> The changes you need to make to a Python program to enable it to be type checked result in more bugs being added than the type checker removes leaving you at a net negative.

This claim doesn't make sense to me. Assuming mypy is regularly run as part of CI, why would adding type annotations cause more bugs than leaving it off?

Re: Python’s “type hints” are a bit of a disappointment to me

#468

Post by toolslive »

ImprobableTruth wrote: post #464
toolslive wrote: post #400

Earlier quoted context omitted.

> JSON = Union[....] This does not define the type of a valid json object. (fe None is not a valid json object, neither is '')

A decade or so ago JSON was changed so that JSON text doesn't have to be an object, it can also be a value. 'null' (or say, '5') is therefore legal JSON.

you're right: https://www.rfc-editor.org/rfc/rfc8259.txt

Re: Python’s “type hints” are a bit of a disappointment to me

#469

Post by wheelerof4te »

mountainriver wrote: post #233
linsomniac wrote: post #180

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…

Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work

Yeah, especially types like:

  List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]
Oh, so I am supposed to make my own data structures now, just for typing?

How about no?

Re: Python’s “type hints” are a bit of a disappointment to me

#470

Post by nine_zeros »

Spivak wrote: post #459
nine_zeros wrote: post #427

Earlier quoted context omitted.

Python types just work. Just use these 30 libraries, spice up your IDE with settings and voila /s. This is garbage and moving backwards as a programmer. I loved python when it was easy to use with any editor and with few plugins. Now I'm just going to switch to a statically typed language where I don't have to install a zillion plugins to get first class typing.

Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.

My codebase is more complex than str, text, dict, int, bool.

So developers are creating complex custom types with union[custom_type_1, custom_type_2] where each custom type could have more unions of other custom types. These custom types then get imported everywhere. It is utter garbage.

Post reply on HN