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

211–220 of 597 posts

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

#211

Post by valcron1000 »

gorgoiler wrote: post #162

I never liked how go makes you fix all your types before letting you run a program. Suppose I wanted to hack something up and run it, just as a new idea? Maybe change a library function that is called in 20 places, but I only want to test it in one call site. Nope! Go forces you to polish up your turd of an idea in all 20 call sites before you can see that your algorithm / model / refactoring is nonsense. If you back…

The only compiled language that I know that supports this kind of development is Haskell by enabling '-fdefer-type-errors'

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

#212

Post by Matheus28 »

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…

> you can't do this _at all_ in many statically compiled languages

What statically compiled language doesn't provide a way (sometimes clunky) to have heterogeneous values in a dict? You can do that with void* in C, even

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

#214

Post by hannofcart »

Humphrey wrote: post #118

While I love the idea behind Python's type hints, they are merely a shadow of the success of TypeScript. Like the author, I've mostly given up on adding type hints in my Python code. I now only use them when I want to help my IDE find autocomplete suggestions. Whereas TypeScript was a game changer for JavaScript. I used to hate JavaScript, but somehow TypeScript has become one of my favourite languages! How has the a…

To be fair, you're comparing a static typed language that transpiles to JS with a type annotation system for a dynamic lang.

Pylint is closer to Flow than Typescript.

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

#216

Post by rglullis »

the_af wrote: post #200
rglullis wrote: post #191

Earlier quoted context omitted.

> generally better than dynamic languages for most use cases Shouldn't then the exercise be to figure out if these use cases are applicable to your situation? What is your team and company optimizing for? > How else will languages improve if nobody is working on addressing their pain points? "See, at my work we need to travel between two islands as fast and cheap as possible. My team is used to high-speed motorboats,…

Your "islands" anecdote is amusing, if a bit condescending. Do you honestly think it fairly addresses the very direct question I asked you? Also, do you honestly expect me to detail what my team and company is optimizing for here? What for? What does it have to do with Python type hinting?

The problem I see is that you are trying to peg a square in a round role and thinking that the square is at fault for not being flexible enough.

Anyone that has seen the py2 -> py3 debacle will tell you that "let's make python static" is not something that could happen unless you are willing to rewrite the entire ecosystem of libraries and applications, and quite possibly upsetting the majority of current users who were attracted to it in the first place precisely because it is so easy to get started with it.

You can not turn Python into a "fully static" language without changing it so much to the point of making into a different beast. And why should others make all this work to fit into your view of what is "best" when you can just use another language in the first place?

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

#217

Post by reikonomusha »

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?

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 calling it gradual typing is baffling. It's just adding metadata-that-doesn't-look-like-metadata that sophisticated programs that aren't part of the Python bytecode compiler can use. The definition I know is the same one from Wikipedia:

> Gradual typing is a type system in which some variables and expressions may be given types and the correctness of the typing is checked at compile time [...]

This is definitely not what Python is doing.

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

#218

Post by ZephyrBlu »

ImprobableTruth wrote: post #103
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…

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.

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

#219

Post by reikonomusha »

woodruffw wrote: post #156
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? Python is both strongly typed and protocol-typed. In the case of `print(...)`, the protocol is that the received parameter responds to `str(...)` (i.e., has `__str__`). (What Python isn't is statically typed. But "strong" and "static" are completely different typing dimensions.)

I think the person you're responding to means to ask

> In what reasonable sense can Python be said to "enforce statically declared types at runtime" here?

which is certainly an extremely pertinent question for a language that allows declaring supposedly static qualities of a program.

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

#220

Post by ReflectedImage »

noitpmeder wrote: post #163
nine_zeros wrote: post #38

In my experience, people with less experience with object oriented programming will end up creating lots of objects only to create types. These objects have no business use case, nor do they aid in any encapsulation. These objects are made just to help typing. Nuts! Python type hinting is like moving backwards in time because the amount of time devs take to "hint", takes away the main reason for using python, that is…

This has to be a troll comment. The overhead of typing is literally _nothing_ compared to the amount of time it takes to sift through code to figure out a) what types a function/class accepts as arguments and b) what types are returned. If you don't check it then I agree it's useless. However, working with libraries that are typed is an _insane_ productivity boost over working with untyped libraries.

Typing in Python is generally a code smell.

Typing encourages a large number of bad coding practices. If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code.

In Python world, unit tests cover what is normally handled by typing.

Post reply on HN