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

581–590 of 597 posts

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

#581

Post by rglullis »

the_af wrote: post #579
rglullis wrote: post #578

Earlier quoted context omitted.

> maybe voice an opinion of your own In regards to "type hinting/type checking" in Python, my "opinion" is somewhat similar to automated testing: "use it when it can help increase your confidence about the soundness of your program and its design, but don't rely on it as a guarantee of it being bug-free." In regards to the article, my opinion is that if you want to claim "disappointment" with a language your expectat…

> First, not rules but guidelines. Second, you have been responding with passive-aggressive insults and retorts which also makes for unpleasant conversation. You continue nitpicking! You would do better if you followed those "guidelines". Indeed this conversation has been unpleasant, but it's all on you. You have been condescending and insulting. I suggest you focus your energies on better enterprises next time, mayb…

I thought you were going to let me have the last word. ;)

> someone who thinks "my argument doesn't have any merit" (and who doesn't think that's insulting)

You forgot the yet. No, it's not nitpicking. Without it, it would be a mere judgmental sentence and it would make sense if you felt dismissed. With it, it is a sign that I am trying to reach for a point of agreement or an understanding.

You are claiming I am the one "biting and nitpicking on everything", but you also could've given a much more charitable interpretation to this, much like you could have done it for the last 6-7 exchanges we had.

And sorry, but I really don't see what is "insulting" about it. Well, at least I don't see how this is insulting if we are to have a rational conversation. This would be insulting only for those who'd be tying their self-image to any of the things being discussed.

> Honestly, hand on your heart, do you believe your responses were made in the best possible tone and were the best way to conduct an honest conversation?

Yes...?

Maybe I am relying too much on the Socratic method, but my questions were mostly to dig in for Truth, not to grieve you. But given the way that old man died, perhaps I should try a different path to not end on the same way as he did.

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

#582

Post by the_af »

rglullis wrote: post #581
the_af wrote: post #579

Earlier quoted context omitted.

> First, not rules but guidelines. Second, you have been responding with passive-aggressive insults and retorts which also makes for unpleasant conversation. You continue nitpicking! You would do better if you followed those "guidelines". Indeed this conversation has been unpleasant, but it's all on you. You have been condescending and insulting. I suggest you focus your energies on better enterprises next time, mayb…

I thought you were going to let me have the last word. ;) > someone who thinks "my argument doesn't have any merit" (and who doesn't think that's insulting) You forgot the yet . No, it's not nitpicking. Without it, it would be a mere judgmental sentence and it would make sense if you felt dismissed. With it, it is a sign that I am trying to reach for a point of agreement or an understanding. You are claiming I am the…

> "Maybe I am relying too much on the Socratic method, but my questions were mostly to dig in for Truth, not to grieve you."

Oh. My. God.

A Socrates complex.

I give up.

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

#583

Post by rglullis »

the_af wrote: post #582
rglullis wrote: post #581

Earlier quoted context omitted.

I thought you were going to let me have the last word. ;) > someone who thinks "my argument doesn't have any merit" (and who doesn't think that's insulting) You forgot the yet . No, it's not nitpicking. Without it, it would be a mere judgmental sentence and it would make sense if you felt dismissed. With it, it is a sign that I am trying to reach for a point of agreement or an understanding. You are claiming I am the…

> "Maybe I am relying too much on the Socratic method, but my questions were mostly to dig in for Truth, not to grieve you." Oh. My. God. A Socrates complex. I give up.

I extended a olive branch, made a self-deprecating post and your response is a metaphorical "ha-ha" finger-pointing, like an eighth-grader?

I guess you were right all along, this conversation should've ended two days ago. You win the xkcd 386 today. Good night and good luck.

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

#584

Post by the_af »

rglullis wrote: post #583
the_af wrote: post #582

Earlier quoted context omitted.

> "Maybe I am relying too much on the Socratic method, but my questions were mostly to dig in for Truth, not to grieve you." Oh. My. God. A Socrates complex. I give up.

I extended a olive branch, made a self-deprecating post and your response is a metaphorical "ha-ha" finger-pointing, like an eighth-grader? I guess you were right all along, this conversation should've ended two days ago. You win the xkcd 386 today. Good night and good luck.

Thank you. Finally! Goodbye.

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

#585

Post by nine_zeros »

saila wrote: post #577
nine_zeros wrote: post #561

Earlier quoted context omitted.

I am amazed at how much time some devs will waste on trying to figure out type annotations, at the expense of actual work time.

Learning any new syntax, feature, etc takes time. IME learning type annotations can pay major dividends. For example, I wrote some type-annotated code the other day and mypy pointed out a couple places where I was passing the wrong type, which saved me from having to fix those bugs later, thus saving time for "actual work."

There is a recurring cost to complex type annotations and that is that every single developer working on that repo (could be thousands) has to unravel the complex types, their aliases and the instance objects to modify any code.

This as opposed to a legitimate type system where complex types are classes themselves which don't need unraveling. There is no need to alias a type and there is no need to maintain separate complexities for the object and the type.

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

#586

Post by mbrodersen »

michaelt wrote: post #462
eweise wrote: post #446

Earlier quoted context omitted.

Why not just use a statically type language? I really don't understand why python is so popular outside of a few specialized areas.

Ah, but what if I'm a masochist and I want all the verbosity of a statically typed language with none of the benefits?

Try F#: Strongly typed but 100% inference of types => best of both worlds.

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

#587

Post by deterministic »

coder543 wrote: post #263
tootie wrote: post #254

Earlier quoted context omitted.

I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.

There are way more differences between Python and Java than just "having explicit types". If that was the only difference, your comment would make more sense. I would even go so far as to say that Java's type system is the very one that left such a bad taste in people's mouth that many people swore off explicitly typed languages for a decade or two. It really was that bad, especially before the last few years. It add…

F# is a great example of a strongly typed language where you almost never have to write type’s explicitly. The best of both worlds IMHO.

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

#588

Post by RhysU »

phailhaus wrote: post #292
RhysU wrote: post #251

Earlier quoted context omitted.

If you have a dictionary with heterogenous, optional keys then I believe you have a struct-like class. If you have any constraints on the keys beyond a homogeneous domain and a homogeneous range then you have a struct-like class.

Avoiding classes has a couple of benefits: 1. It reduces the overhead to use your interface. Your users don't have to import your struct classes, and can just pass in bare dictionaries. If Python's typing was more effective, these dictionaries would also be type checked to make sure you're calling the library's APIs correctly. 2. It deliberately closes off the option of adding state or initialization logic. Classes l…

You want keyword arguments given these constraints. The type checker will confirm anything you like about those.

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

#589

Post by the_af »

dragonwriter wrote: post #504
the_af wrote: post #138

Earlier quoted context omitted.

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!).

They are for documenting and checking. Obviously, if static typing is your only concern, you wouldn't have picked Python to start with, but if you did have a reason to pick Python, you can get a large subset of the value of static typing for correctness and dev-tine information via Python’s support for type hints and the typecheckers (mypy keeps getting pointed to, but it's not the only one) that support it.

Yes, obviously. There are outside factors why Python was chosen. I tend to work with whatever language is needed, and try to make the best of it.

I've tried mypy and pytype, and found both to be unsatisfying and hard to sell to the team (which as I mentioned, don't even like writing tests). If you're thinking "well, that's a culture/professionalism rather than a technical problem", you are absolutely right! But I'm left wondering if a language that was better at static typing would be better because, a- the checking would be mandatory, and b- it would be demonstrably more effective than Python's "optional" checking/hinting. At least it'd remove one variable from the problem. Or maybe not, who knows.

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

#590

Post by Bedon292 »

folkrav wrote: post #498
Bedon292 wrote: post #408

Earlier quoted context omitted.

Yeah, when you just want to add a checkpoint WIP commit its annoying. Hate having to fight with that. But it prevents people form submitting a PR and then just having CI fail anyways. I could see it being nice to only enforce on CI though. Sucks seeing those red builds because someone didn't run something manually.

I don't see it as a big issue as we just assume PRs with failing builds not to be ready for review and push them back to draft. But whatever works for your team, honestly. In the end what matters is having a CI acting as authority source, the rest is simply workflow related.

Yeah, think its just a difference in mindset. Some teams strive to never have failed builds, while others don't care because its all part of the process. I think we were more in the mindset of you should never push a failing build initially, but have moved more towards its all part of the process.
Post reply on HN