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

131–140 of 597 posts

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

#131

Post by icedchai »

minusf wrote: post #95
gnulinux wrote: post #72

Earlier quoted context omitted.

It is good for programmers. Programmers think in many different ways, but it seems to me that a sizable portion of programmers think of code in terms types. Type hinting makes it easy to convey type ideas. Where are we going from which type. I should say that anecdotally I find type hinting very useful when I'm reviewing a PR from a part of the code I'm not intensely familiar with.

when types are not checked and enforced, they get out of date just like comments and docstrings. i agree with the author, if the hints can't be trusted, even just once, there's no point littering the code with them, and are actually harmful when trying to debug something using faulty hints. i am a big fan of static typing but not in python. pick a language that was designed around it. you can't make a duck bark.

For libraries, with many consumers of the code, type hinting seems like a good thing. Many times I download a third-party library and waste tons of time looking at sample code. For application code (internal to the service or whatever), it feels less valuable.

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

#132

Post by Frotag »

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…

This is exactly my experience. I've also found that Python's type annotations for even basic stuff like are way clunkier to write.

For example an optional requires a typing.Optional import or a an ugly "| None" instead of a question mark like TS has. And good luck trying to annotate some complex / nested json, you'll need a bazillion intermediary classes.

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

#133

Post by lifewallet_dev »

forrestthewoods wrote: post #22
jonathan-adly wrote: post #7

100% agree - never really understood the movement behind adding types to Python. Type hints are a useless complexity that yield little return. If you want types, use something else other than Python. The whole thesis behind Python is simple is better than complex.

> If you want types, use something else other than Python. Python is still strongly typed. Me: what type does this argument need to be? Python: you have to figure that out Me: I just pass whatever I want? Python: Oh no. Usually only a single specific type is supported. But you have to guess what it is. Me: what if I get it wrong? Python: the program crashes at runtime

You don't understand what "strongly typed" means... I give you a hint, `"1" == 1` is a type error in Python but "okay" in JavaScript because this one is "weakly typed", you're confusing "dynamic typing vs static typing" with "strongly typed vs weakly typed".

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

#134

Post by AnimalMuppet »

the_af wrote: post #58
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 agree with most of your comment, but I think there's a miscommunication problem here. When Python "enforces types at runtime" this is the actual types, not type hints. Type hints are not a runtime artifact. The "actual type" here is "string", and enforcing it means Python would not allow invalid operations on it without error'ing. A programming language that will let you do basically anything to any value because i…

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, or an array to a pointer, or... well, it will let you convert lots of things to lots of things. Some of those things are unsafe unless you are quite sure what you're doing.

> A programming language that will let you do basically anything to any value because it doesn't enforce type safety is of course C.

False on several grounds. You can't call something that isn't a function. You can't call a function on something that doesn't have it. You can't use an int as a pointer or an array without casting it. You can't use an int as a dict (not that C has any built-in idea of what a dict is...)

> Python is safer than C.

Depends on what you're doing, and what kinds of errors you are more prone to.

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

#135

Post by the_af »

ledauphin wrote: post #129
the_af wrote: post #101

Earlier quoted context omitted.

> Yes, it is possible to annotate types in Python incorrectly. It's possible to do this in all other languages that allow type-unsafe behavior (whether natively or via reflection, etc). This may be less common in some languages than in others, but it is fundamentally possible in the vast majority of languages that perform static typing, because those types are fundamentally enforced at analysis time, not runtime. It…

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 just me or the article's author.

As a fan of statically typed languages, I do indeed find some Python programmers engage in a form of Stockholm's syndrome. It usually takes the form of the assertion "I never found a bug that was a type error". Have you or anyone you know ever said this?

In my mind, the opposite statement of the one you attribute to me would be "wishful thinking and a positive attitude is enough to catch mistakes, it's not necessary to have help from automated tooling". In this day and age, I cannot disagree more.

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

#136

Post by patrick451 »

daenz wrote: post #23

Opinions like these are frustrating because, although they make valid points, it comes off as "they didn't do 100% exactly what I want, so I'm not using them at all." With many tools, there is a middle ground between using them for everything, and not using them at all. Python's type hints is one of those tools. When I'm writing code, and a variable or signature is easy to annotate, I'll annotate it. And guess what?…

Letting perfect be the enemy of the good is not the same thing as doing a cost benefit analysis. In the authors estimation, the costs outweigh the benefits. You don't seem to be considering the cost of type checking at all.

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

#137

Post by spoils19 »

fluster wrote: post #108
the_af wrote: post #65

Earlier quoted context omitted.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

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…

> don't feel like writing `private static final synchronized` forty time, type hints are great.

We should think about whether there's a reason why we want to be writing `private static final synchronized` over and over again, after looking at the state of the software engineer these days.

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

#138

Post by the_af »

xarope wrote: post #128
the_af wrote: post #73

Earlier quoted context omitted.

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).

it's a comment which can trigger an action (if you run mypy). So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc) (btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)

Now I'm confused because the root comment I was replying to asserted that type hints are for documenting, not for checking.

If they are for checking, then my other opinion stands: that they are not very good at it (compared to my experience with statically typed languages, even with Typescript!).

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

#139

Post by Animats »

That's about what I said when the idea was first proposed. Actual type declarations, both enforced and used to guide code generation and optimization, would be fine.

Part of the problem is that, in the minds of many, Python == CPython. PyPy, which is a real compiler, is viewed as "nonstandard". For PyPy, type information, although not in type hint form, would be useful. But type hints, as currently defined, are not. See the commentary on type hints at [1].

[1] https://doc.pypy.org/en/latest/faq.html

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

#140

Post by the_af »

AnimalMuppet wrote: post #134
the_af wrote: post #58

Earlier quoted context omitted.

I agree with most of your comment, but I think there's a miscommunication problem here. When Python "enforces types at runtime" this is the actual types, not type hints. Type hints are not a runtime artifact. The "actual type" here is "string", and enforcing it means Python would not allow invalid operations on it without error'ing. A programming language that will let you do basically anything to any value because i…

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 reasonable sense can Python be said to "enforce types at runtime" here?"

Here's a nitpick of my own to your post:

> "Some of those things are unsafe unless you are quite sure what you're doing."

Wrong. Type (un)safety does not depend on you "being quite sure of what you're doing".

PS: assume I know C and that I've programmed complex things using it. No need to catch yourself with statements like "not that C has any idea of what a dict is". Assume we are both C programmers. It will make you sound more polite.

Post reply on HN