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

141–150 of 597 posts

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

#141

Post by ledauphin »

tialaramex wrote: post #126
ledauphin wrote: post #87

Earlier quoted context omitted.

static in this case can be understood to mean simply "prior to (or separate from) runtime". In other words, it's based on what you can check _without_ running the code. It's worth noting that nearly every statically-typed language currently in existence has two separate "type systems" - the static type system which is the formal type system offered to the programmer, plus a runtime type system enforced, at minimum, b…

> It's worth noting that nearly every statically-typed language currently in existence has either two separate "type systems" Either that or... ? You should probably complete this thought. I don't think the distinction you've claimed make much sense, but perhaps you had an alternative which you just never explained.

that was a typo - no "either" was intended. I've amended the original. not sure if that will help clarify?

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

#142

Post by ledauphin »

the_af wrote: post #135
ledauphin wrote: post #129

Earlier quoted context omitted.

I think your (and the article's) argument could be summarized as "static type annotations without automated enforcement by actually running a type checker considered harmful". Since this argument is not meaningfully different from "comments that are lies considered harmful", it seems fair to expect reasonable people to dismiss it as uninteresting.

> it seems fair to expect reasonable people to dismiss it as uninteresting. Do you think that's a fair treatment of someone who disagrees with you but has been respectful of your opinion so far? I realize proglang debates are flamewar territory. But I have been very careful to state I find Python type hints puzzling and less useful than they should be. It is obviously an interesting opinion shared by many others, not…

I'm very confused by your response. Where did I suggest that I don't like type systems or think automated tooling is not useful?

It's precisely because I do like and use them that I find Python's static type hints to be extremely useful for large Python codebases.

What I hear you saying is "Python does not offer these things". What I hope you hear me saying is "Python does, in fact, offer these things".

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

#143

Post by rglullis »

the_af wrote: post #109
rglullis wrote: post #96

Earlier quoted context omitted.

You can have mypy doing the type checking . Just put it on your CI pipeline alongside your tests.

I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.

Do your co-workers also only see the point of automated testing if you have 100% coverage?

If you/your team want to use a statically typed language, then use one. Python is not it.

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

#144

Post by uranusjr »

the_af wrote: post #115
fluster wrote: post #108

Earlier quoted context omitted.

I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing. Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you…

Thanks for your reply. > I view them as similar to python's "private" functions, which are really just functions starting with an underscore Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally. Wh…

> That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view.

That’s the kind of the culture shock you get learning dynamic type languages with a static type pov. Type hinting is not really the problem here, but can seem that way because it makes dynamically typed code too superficially similar that it enters the uncanny valley if you treat it like statically typed.

One way that might make this easier is to forget about type hinting entirely at first and learn the language “from scratch”, and add the types back after you get used to write dynamically typed code. Dynamically typed code have its advantage and isn’t bad without type hints (well, at least you have to convince yourself on this, or you’ll never be able to learn a dynamic type language), and the type hints just add back some of the nice things static type provides without compromising dynamic type benefits.

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

#145

Post by AnimalMuppet »

the_af wrote: post #140
AnimalMuppet wrote: post #134

Earlier quoted context omitted.

Yes and no. C will let you do things like: *(unsigned long*)0xFFFFFF14 = 0x749235f8; It will not let you do things like: *0xFFFFFF14 = 0x749235f8; or char* s = "abc"; *(unsigned long*)0xFFFFFF14 = s; It also won't let you call thing.method without thing.method definitely existing. Best of all, all of these are enforced at compile time. Now, C absolutely will let you convert an int to a pointer, or a char to an int, o…

I find this level of nitpicking puzzling. You know what I meant and what error I was clarifying for the comment I was replying to. Yet you went out of your way to point all sorts of irrelevant mistakes in my post, when the gist of it was right. Do you feel it was more important to correct me on these trivial things, or was my reply more or less correct when fixing the conceptual error in this sentence?: > "In what re…

1. You might need to re-read the site guidelines about assuming good faith.

2. Your last two sentences were, I think, not needed for the point you were making. They were also somewhere between gross generalizations and flat-out wrong, and felt like a gratuitous slam on a language that wasn't even the topic. I thought that deserved a response, even if it wasn't your main point.

3. I may assume that you know C. I don't assume that everyone reading this exchange knows C.

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

#146

Post by nomel »

the_af wrote: post #106
nomel wrote: post #102

Earlier quoted context omitted.

As someone who lives in an IDE, I don't understand this. Trying to get all of the functionality of the default IDE, along with the trivially added plugins, to work in a visually digestible and sane way would be a curses nightmare of 30 command line tools. If you made it so they played well together, where a human could interpret what they were seeing, you would have something indistinguishable from an IDE.

I find your opinion baffling to be honest. It's simply not true. Every statically typed language works like I described. Even Typescript works like this. You can have your IDE plugins, but you definitely don't need them to perform type checks. It's not true this requires "a nightmare of 30 command line tools", you just need one: the type checker (built into the language in most statically typed languages, but sometim…

Sorry, I misread your comment.

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

#147

Post by icedchai »

ledauphin wrote: post #76
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?

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 ClassCastException, or worse (ClassNotFoundException if you have the wrong classloader.) This is a runtime error.

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

#148

Post by the_af »

ledauphin wrote: post #142
the_af wrote: post #135

Earlier quoted context omitted.

> it seems fair to expect reasonable people to dismiss it as uninteresting. Do you think that's a fair treatment of someone who disagrees with you but has been respectful of your opinion so far? I realize proglang debates are flamewar territory. But I have been very careful to state I find Python type hints puzzling and less useful than they should be. It is obviously an interesting opinion shared by many others, not…

I'm very confused by your response. Where did I suggest that I don't like type systems or think automated tooling is not useful? It's precisely because I do like and use them that I find Python's static type hints to be extremely useful for large Python codebases. What I hear you saying is "Python does not offer these things". What I hope you hear me saying is "Python does, in fact, offer these things".

Well, you did frame the discussion as:

> I think your (and the article's) argument could be summarized as "static type annotations without automated enforcement by actually running a type checker considered harmful"

It illustrates your mindset, in my opinion. I think type annotations without checking them (or without a satisfying implementation of said type checking) are mostly pointless.

You also left out the part where I remarked on the dismissive tone of your reply.

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

#149

Post by the_af »

uranusjr wrote: post #144
the_af wrote: post #115

Earlier quoted context omitted.

Thanks for your reply. > I view them as similar to python's "private" functions, which are really just functions starting with an underscore Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally. Wh…

> That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. That’s the kind of the culture shock you get learning dynamic type languages with a static type pov. Type hinting is not really the problem here, but can seem that way because it makes dynamically typed code too superficially similar that it enters the uncanny valley if you treat i…

Agreed, but it also clashes with the world view that brought us Typescript, which I also find better than Python's type hinting.

In addition, it makes it harder for me to argue in favor of type annotations with my coworkers. My coworkers come from neither world, static or dynamic; they are learning the ropes. And they just can't see the point. I'm confident I would convince them were this a statically typed language, but with Python I'm lost.

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

#150

Post by lolinder »

ledauphin wrote: post #123
theodorejb wrote: post #97

Earlier quoted context omitted.

> 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. Counterexample: PHP is a dynamic language which enforces static type declarations at runtime.

Meh. you can do the same thing in Python if you really want - there are dynamic interpreter shims that can do this. The point is that it is not expected by definition, since by definition, static != runtime.

You're assuming that type hints are by definition static-only. There's no particular reason why type hints can't be both statically and dynamically enforceable, as they are in PHP.
Post reply on HN