Python’s “type hints” are a bit of a disappointment to me • Hacker News Board

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

#241

Post by woodruffw » Fri, Apr 22, 2022, 2:14 AM UTC

reikonomusha wrote: post #223

heavyset_go wrote: post #206

Earlier quoted context omitted.

> In what reasonable sense can Python be said to "enforce types at runtime" here? In [1]: foo: int = 'hello' In [2]: foo + 1 TypeError Input In [2], in () ----> 1 foo + 1 TypeError: can only concatenate str (not "int") to str

This is a demonstration that it has not enforced what many would reasonably believe is a static type declaration. But we have (to quote another commenter) "uneducated" people making a supposedly boneheaded mistake to assume x: T = y is a declaration that x will only contain values of type T, or otherwise something will be detected by cpython as invalid (at either bytecode-compile-time or run-time). Instead, this line…

Type hints are not static type declarations. Python does not refer to them as such, nor does Mypy or any other typechecker for Python type hints.

Absent of active machine checking (e.g., via mypy), type hints should be considered exactly what you said: another form of documentation, one that might just be wrong.

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

#242

Post by throwaway287391 » Fri, Apr 22, 2022, 2:16 AM UTC

reikonomusha wrote: post #217

civilized wrote: post #63

Earlier quoted context omitted.

It seems that your point boils down to "Python enforces types at runtime if you define 'enforce types at runtime' not to include 'enforcing that data you declare to be of a certain type actually is of that type'". Am I the only one baffled by this way of thinking?

No, you're not the only one. All of these gymnastics to justify the behavior of the string-declared-int baffle me. Is it "legally" baffling, i.e., do I understand why this behaves in the way it does purely mechanically, and do I understand the arguments the gymnasts are making? Yes. But from an idiomatic, colloquial, linguistic, syntactic, programming-historical, or programming-cultural standpoint? Baffled. Even call…

> This is definitely not what Python is doing.

Maybe not by default but there is tooling that makes it work that way — that’s exactly how the python build system works at my company. I don’t know the details but when I “build” python code (creating bytecode pyc files) it produces compiler errors and fails to build if I e.g. try to pass an int to an f(x: str). This has usefully caught bugs before I ran some expensive/time-consuming scripts.

I guess you could say this doesn’t count as it’s a separate program doing the type checking but IMO there’s not a clear distinction between that and e.g. having a first type checking pass in the “same” compiler program.

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

#243

Post by reikonomusha » Fri, Apr 22, 2022, 2:17 AM UTC

woodruffw wrote: post #241

reikonomusha wrote: post #223

Earlier quoted context omitted.

This is a demonstration that it has not enforced what many would reasonably believe is a static type declaration. But we have (to quote another commenter) "uneducated" people making a supposedly boneheaded mistake to assume x: T = y is a declaration that x will only contain values of type T, or otherwise something will be detected by cpython as invalid (at either bytecode-compile-time or run-time). Instead, this line…

Type hints are not static type declarations. Python does not refer to them as such, nor does Mypy or any other typechecker for Python type hints. Absent of active machine checking (e.g., via mypy), type hints should be considered exactly what you said: another form of documentation, one that might just be wrong.

This is my point precisely: it looks like a static type declaration to anybody who has seen what a static type declaration looks like in any statically or gradually typed program in the last 50 years.

But in Python, it's not (and documented in a PEP as not), and it causes massive confusion.

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

#244

Post by Lendal » Fri, Apr 22, 2022, 2:19 AM UTC

ainar-g wrote: post #26

Lendal wrote: post #8

I tried mypy when I first started into type checking in Python back when I was trying to do Python in VS Code and I discovered that mypy is a time-sucking anti-productivity disaster that needs to die in a fire. When I started learning PyCharm though, I discovered that type checking can actually work well in Python and it is not a waste of time at all. So I advise people now that unless you're using PyCharm, do not wa…

Could you elaborate on mypy? I'm not a Python developer (and I really have much more experience with statically typed languages), but if I ever had to maintain a Python codebase, I'd assume that adding mypy and type annotations would be among the first things I'd do, so it's a bit of a surprise to read that.

I spent a lot of time trying to configure pypy in VS Code, time that I didn't have to spend in other languages such as TypeScript, and I never did get it working as well as it does in PyCharm. PyCharm comes already configured. You don't have to do anything for typing. Works out of the box. VS Code is like that with TypeScript but not for Python. That was a couple of years back so maybe it's different today. I hear VS Code's PyLance extension works but I've already made the switch to PyCharm. I might try it out later.

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

#245

Post by reikonomusha » Fri, Apr 22, 2022, 2:23 AM UTC

throwaway287391 wrote: post #242

reikonomusha wrote: post #217

Earlier quoted context omitted.

No, you're not the only one. All of these gymnastics to justify the behavior of the string-declared-int baffle me. Is it "legally" baffling, i.e., do I understand why this behaves in the way it does purely mechanically, and do I understand the arguments the gymnasts are making? Yes. But from an idiomatic, colloquial, linguistic, syntactic, programming-historical, or programming-cultural standpoint? Baffled. Even call…

> This is definitely not what Python is doing. Maybe not by default but there is tooling that makes it work that way — that’s exactly how the python build system works at my company. I don’t know the details but when I “build” python code (creating bytecode pyc files) it produces compiler errors and fails to build if I e.g. try to pass an int to an f(x: str). This has usefully caught bugs before I ran some expensive/…

I don't know the latest but PEP 484 writes:

> While these [type] annotations are available at runtime through the usual __annotations__ attribute, no type checking happens at runtime. Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily.

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

#246

Post by woodruffw » Fri, Apr 22, 2022, 2:24 AM UTC

reikonomusha wrote: post #234

woodruffw wrote: post #232

Earlier quoted context omitted.

> In what reasonable sense can Python be said to "enforce statically declared types at runtime" here? It can't, because Python doesn't have statically declared types. It's a strong, dynamically typed language. Python also doesn't allow you to declare static types. It allows you to declare type hints , which are a sort of adjacent and potentially unrealistic (or just plain incorrect) typechecking proof that doesn't co…

If your statement were absolutely true then a product like mypy would neither exist nor provide value. Python has the capacity to have some form of gradual typing built-in at the language level, but it does not, which has led to the enormous confusion we have before us. The SBCL implementation of Common Lisp is a great example of a strong, dynamically typed language that is able to, when possible, detect errors stati…

> If your statement were absolutely true then a product like mypy would neither exist nor provide value.

I don't see why that would be the case. The value of Mypy is that it's essentially a proof language over something that resembles Python[1]: it's a way to do some amount of static typing without having to maintain a separate copy and representation of the program.

And sure: Python could detect inconsistent type hints at runtime. But why would it? It's already strongly typed, and the presence of type hints usually means that someone is already running Mypy or another checker during development. It's not clear that there's a significant advantage to be gained, particularly one that justifies the additional overhead.

[1]: "Resembles Python" because mypy does not actually evaluate any Python. It doesn't know what types your program has at runtime; it only knows type hints and a few small rules (for things like string literals) and trusts the developer to reconcile those rules with Python's runtime behavior.

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

#247

Post by kadoban » Fri, Apr 22, 2022, 2:27 AM UTC

icedchai wrote: post #147

ledauphin wrote: post #76

Earlier quoted context omitted.

Python does and always has enforced types at runtime. This is called duck-typing. If you're not familiar with the concept of strong+dynamic, it is easy to see how this could be confusing. This may help. https://stackoverflow.com/questions/2351190/static-dynamic-v... Static type annotations by definition are not enforced at runtime. This has been true of every language that has ever used static typing, including C, C+…

Duck typing is really enforcement of interfaces , not types themselves. Everyone who has passed a string into a Python method expecting a list of strings has run into this. It works, but did you really want to process a character at a time? Also, some languages like Java do actually enforce types at runtime. If you've ever called a Java method dynamically with the wrong types, you'd know. You can run into ClassCastEx…

> Duck typing is really enforcement of interfaces, not types themselves

A type system is just a set of rules that must be followed. The rules can be as weird or as simple as you want. Just because + is allowed doesn't mean it's not enforcing types.

Not really a criticism, just trying to push to expand your idea of what a type system is.

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

#248

Post by reikonomusha » Fri, Apr 22, 2022, 2:27 AM UTC

woodruffw wrote: post #246

reikonomusha wrote: post #234

Earlier quoted context omitted.

If your statement were absolutely true then a product like mypy would neither exist nor provide value. Python has the capacity to have some form of gradual typing built-in at the language level, but it does not, which has led to the enormous confusion we have before us. The SBCL implementation of Common Lisp is a great example of a strong, dynamically typed language that is able to, when possible, detect errors stati…

> If your statement were absolutely true then a product like mypy would neither exist nor provide value. I don't see why that would be the case. The value of Mypy is that it's essentially a proof language over something that resembles Python[1]: it's a way to do some amount of static typing without having to maintain a separate copy and representation of the program. And sure: Python could detect inconsistent type hi…

> Python could detect inconsistent type hints at runtime. But why would it?

Because the programmer explicitly intended a contract which is being violated, which would in turn indicate a bug.

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

#249

Post by d0mine » Fri, Apr 22, 2022, 2:29 AM UTC

civilized wrote: post #44

ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

> not-very-educated thoughts on gradual typing This seems like an inaccurate and condescending put-down. What is the definition of "educated" in this context? Is there a book or generally well-known resource? The author is clearly thoughtful and curious. Near the top of the post he says "what I’m hoping for is that someone will come along and tell me that I got it all wrong. “When you do it as follows, the system wor…

Don't confuse strong typing and static typing.

Python is strongly typed. It respects types at runtime e.g., `"1"+1` causes TypeError. Python is not statically typed.

For comparison, C is statically typed but it is weakly typed e.g., printf function has no idea about actual types of its arguments (in particular, errors in the format arg may produce non-sensical results silently).

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

#250

Post by throwaway287391 » Fri, Apr 22, 2022, 2:30 AM UTC

reikonomusha wrote: post #245

throwaway287391 wrote: post #242

Earlier quoted context omitted.

> This is definitely not what Python is doing. Maybe not by default but there is tooling that makes it work that way — that’s exactly how the python build system works at my company. I don’t know the details but when I “build” python code (creating bytecode pyc files) it produces compiler errors and fails to build if I e.g. try to pass an int to an f(x: str). This has usefully caught bugs before I ran some expensive/…

I don't know the latest but PEP 484 writes: > While these [type] annotations are available at runtime through the usual __annotations__ attribute, no type checking happens at runtime. Instead, the proposal assumes the existence of a separate off-line type checker which users can run over their source code voluntarily.

Right, it’s definitely still a voluntary feature. What I meant is if you opt in and make it part of your project’s standard build procedure for python code, you effectively get the behavior and benefits of “compile-time type checking” (to the extent that you actually use type annotations in your code).