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

221–230 of 597 posts

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

#221

Post by School-Cotton »

civilized wrote: post #63
ledauphin wrote: post #55

Earlier quoted context omitted.

This one is self-explanatory. Can a string be printed? Yes! Then Python is (correctly) allowing typesafe behavior here. Your (incorrect) annotation does not in any way contradict the typesafe-ness of printing a string (or an int). They're both equally printable. This is just a very, very bad example, plain and simple. It 'looks' bad to a superficial reading, but in practice it demonstrates only what is already known…

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?

This is how all or most statically-typed languages work, too. The typing is purely a compile-time construct.

E.g. this kind of code: https://play.rust-lang.org/?version=stable&mode=debug&editio...

typically works fine (or worse, works fine in debug mode and causes unpredictable UB-related bugs in release mode).

std::mem::transmute here is a no-op at runtime; all it does is subvert the static type checker.

The difference between statically-typed languages and things like Python with type hints is _not_ that the former has any runtime type checking; it’s that subverting the (static!) type system is more difficult and requires more obvious ceremony, and that static type checking is required whereas with Python it’s optional.

If you hacked rustc to disable static typechecking you would get a similar experience to Python with type hints but without any mypy-like tools. (Of course, this would be hard to do in practice, because Rust, like most statically-typed languages, uses types not just for typechecking but also for code generation and method dispatch.)

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

#222

Post by bscphil »

heavyset_go wrote: post #206
civilized wrote: post #44

Earlier quoted context omitted.

> 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…

> 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

Exactly right, great example. And furthermore:

    >>> foo: int = 'hello'
    >>> type(foo)
Python's type annotations are annotations. Types are being enforced at runtime, it's just that some are thinking that annotations have some effect on the interpreter, when they do not.

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

#223

Post by reikonomusha »

heavyset_go wrote: post #206
civilized wrote: post #44

Earlier quoted context omitted.

> 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…

> 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 is more properly interpreted as "documentation reasonably believed to represent a type saying something about values that x can be assigned at runtime, that's not in a docstring, that some programs may query."

I can totally forgive anybody who believes the former over the latter, and expresses their belief in a statement like that which you've quoted.

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

#224

Post by sigzero »

heavyset_go wrote: post #206
civilized wrote: post #44

Earlier quoted context omitted.

> 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…

> 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

Yeah, you are talking about actual types and not type hints. It gets confusing. Python doesn't enforce type hints at runtime.

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

#225

Post by School-Cotton »

hermitdev wrote: post #88
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…

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature. In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic t…

In fact that quote is almost exactly the opposite of the truth. “Dynamic” literally means “at runtime”.

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

#226

Post by derekbaker783 »

ZephyrBlu wrote: post #218
ImprobableTruth wrote: post #103

Earlier quoted context omitted.

I think the top comment was less polite than it should be, but I would echo that the post seems to have a bit of a weird understanding of gradual typing? The Any type is to allow incremental typing. You start out with dynamic code, and progressively 'typify' it by adding more and more annotations, with Any working as a stopgap where for the moment no valid type exists, until you finally have a fully typed program. In…

Like the author said, the weird thing is that it goes both ways. I'm pretty sure if you try to return `any` from a function with an explicit return type in TypeScript you'll get pinged for it.

Not with any TSC settings I've ever used.

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

#227

Post by moonchild »

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…

> If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime

What definition is that? Raku is a dynamically language with gradual typing which will enforce those types at runtime (if it cannot do so at compile time).

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

#229

Post by mountainriver »

bb88 wrote: post #47
chis wrote: post #10

Only facts here. I think most large codebases eventually see type hints drift away from reality as individual contributors are more incentivized to hack in `Any` types to make things compile instead of typing every line properly. This is especially common for handling data objects which come in over the network - often they can have a couple different types but people just type it as one thing for simplicity. Overall…

My understanding was large python code bases (think Google) have a large problem. Someone makes a code change and suddenly it becomes difficult to find the scope of type errors in their monorepo. That was the driving force IIRC. That said, I think pytype makes a lot of sense since it infers types from code, which you can edit by hand and then merge back into the python file when your code is stable.

Yup this is the biggest benefit. Working on a large untyped code base is about as bad as it gets
Post reply on HN