Live data from Hacker News

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

uninformativ.de

571–580 of 597 posts

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

#571

Earlier quoted context omitted.

That's not a silly type, it is just a silly type annotation. It's easy to unpack the tuple inside that list. What is not easy is type-hinting it. What if I want it to be both an list and an iterator? Well, I would have to use Union. I'll leave it to you to write that Union "type".

It is a silly type for a function to return, because you have three levels of data structure nesting, with not one bit of information about the meaning of any of the values except their types. If I call your function and then do result[1][2], what does that mean? This is exactly the kind of situation where you're supposed to use a named tuple or a data class to make it clear what's what.

With tuples inside of lists, you usually unpack them to variables in a for loop.

Named tuples are just immutable classes with slots. Unless you want to slow your code down considerably, it's best to avoid them.

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

#572

Earlier quoted context omitted.

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.

This is a snippet from the python codebase, written by a type nazi SessionInfoType = Union[AuthzQuerySessionInfo, AuthnReqSessionInfo] Notice how it is doing a union of two objects. Do you know what those 2 objects are? Those are types as well. They have no business use case. AuthzQuerySessionInfo = TypedDict( "AuthzQuerySessionInfo", {"name_id": Any, "came_from": Any, "issuer": Any, "not_on_or_after": Any, "authz_de…

No amount of typing will save you from bad code.

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

#573
post #565

Earlier quoted context omitted.

> "What I am trying to say is that perhaps the lesson you could take" I think there's a lesson here, but it's for you rather than me. This is tiring. You keep making stuff up for the sake of argument. I never claimed I didn't like Python; in fact I like it. I never claimed it was Python's fault. I thought you were going to "wait until I realize". Go on waiting, then. Off you go!

I am sorry for my assumption, I just wouldn't think that someone so certain of the superiority of statically typed languages and so disappointed (with a feature that is barely a defining aspect of it) would also claim to like it. Anyway, you also had the chance to respond to other questions I made, but instead you preferred to stick to defensive retorts.

Your questions weren't very reasonable, were they? You made lots of claims about what you supposed I thought. I'm under no obligation to answer, for example, what "my company and team are optimizing for", that's an open ended question which is not reasonable to ask in this context, nor would it benefit me to answer it in any way, nor is it related to the question at hand. It looks like cross-examination, something explicitly discouraged by HN guidelines.

I'm not interested in being "educated". In general, you sound very condescending regardless of your claims that you are not snarky.

It's easier to pick on someone's comments than to make a comment of your own, because that would open you to correction and criticism. I think that's what's going on with you in this case.

Regardless, I suggest you stick to commenting about TFA in the future. It will go better for you. You'll be criticized, but that's par for the course.

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

#574
post #573

Earlier quoted context omitted.

I am sorry for my assumption, I just wouldn't think that someone so certain of the superiority of statically typed languages and so disappointed (with a feature that is barely a defining aspect of it) would also claim to like it. Anyway, you also had the chance to respond to other questions I made, but instead you preferred to stick to defensive retorts.

Your questions weren't very reasonable, were they? You made lots of claims about what you supposed I thought. I'm under no obligation to answer, for example, what "my company and team are optimizing for", that's an open ended question which is not reasonable to ask in this context, nor would it benefit me to answer it in any way, nor is it related to the question at hand. It looks like cross-examination, something ex…

I don't see what is unreasonable about prodding for the "why" of the reasons you gave (which was basically the point of asking what your company wanted to optimize by using Python), and I don't see what is unreasonable about asking what would be your way to solving what "disappoints" you about the typing story without changing the language.

> I'm not interested in being "educated" by knowitalls.

From where I am standing, you are trying to get your coworkers to adopt some practice without a strong case for how it would help them or the bottomline, purely out of your belief that statically languages are better. If you think I am being the know-it-all here, fine.

> It's easier to pick on someone's comments than to make a comment of your own, because that would open you to correction and criticism.

Someone else in the thread already pointed out that your original comment and TFA are basically a statement of opinion, not of fact. I do not see what kind of comment we can have except the meta-commentary.

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

#575
post #573

Earlier quoted context omitted.

Your questions weren't very reasonable, were they? You made lots of claims about what you supposed I thought. I'm under no obligation to answer, for example, what "my company and team are optimizing for", that's an open ended question which is not reasonable to ask in this context, nor would it benefit me to answer it in any way, nor is it related to the question at hand. It looks like cross-examination, something ex…

I don't see what is unreasonable about prodding for the "why" of the reasons you gave (which was basically the point of asking what your company wanted to optimize by using Python), and I don't see what is unreasonable about asking what would be your way to solving what "disappoints" you about the typing story without changing the language. > I'm not interested in being "educated" by knowitalls. From where I am stand…

> I don't see what is unreasonable about prodding [...]

Yes, I can see that you fail to acknowledge the unreasonability of your prodding. Time to change your tack, maybe voice an opinion of your own, on the actual article, and expose yourself to critique?

Maybe drop the condescending tone and try to avoid the cross-examination? It's against the rules on HN.

> I do not see what kind of comment we can have except the meta-commentary.

I can't help you with what you "don't see"; I cannot make you fix your blind spots. I've already told you your meta-commentary is unwanted. I do not welcome it, it's unhelpful, and every single assumption you've made has been wrong (and smug) so far. It's not my job to present my case to you, you're not doing a consultancy here, nor do you demonstrate particular expertise on the subject.

I foresee another pointless reply of your own. I'll let you have the last word.

Bye.

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

#576

Earlier quoted context omitted.

> You can anonymize such data ...thereby destroying the production-like features for which you want it for testing, which you then need to recreate and reintroduce, so you might as well just synthesize test data in the first place, since that's what you end up doing anyway, in effect.

I know you probably just want to be annoying, but really, there is a world of difference between completely synthetic and anonymized data. Without talking about specifics, anonymizing is just the operation of making the process of deanonymization a lot of harder. "Hard enough" is usually specified in some form by the regulator. You can identify an individual by their ECG data, for example, it's just really hard... No…

> I know you probably just want to be annoying, but really, there is a world of difference between completely synthetic and anonymized data.

No, I’ve spent ~20 years in healthcare, with this issue as a frequently recurring issue.

> No, in actual practice you don't scrub the stuff you actually need to test.

In actual practice, the stuff you really need to test often overlaps with the stuff minimally required to scrub to legally deanonymize the data. The most common scenario I’ve seen trying to do this is both creating most of the work of generating synthetic data and failing to legally deidentify the source data.

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

#577

Earlier quoted context omitted.

I would rather see work done on something more useful than new syntax for typing.

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."

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

#578
post #575

Earlier quoted context omitted.

I don't see what is unreasonable about prodding for the "why" of the reasons you gave (which was basically the point of asking what your company wanted to optimize by using Python), and I don't see what is unreasonable about asking what would be your way to solving what "disappoints" you about the typing story without changing the language. > I'm not interested in being "educated" by knowitalls. From where I am stand…

> I don't see what is unreasonable about prodding [...] Yes, I can see that you fail to acknowledge the unreasonability of your prodding. Time to change your tack, maybe voice an opinion of your own, on the actual article, and expose yourself to critique? Maybe drop the condescending tone and try to avoid the cross-examination? It's against the rules on HN. > I do not see what kind of comment we can have except the m…

> 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 expectations should be aligned with the language developers and the general motivations of the community at large. Another opinion is that if the author took the time to understand these underlying motivations there would be no "disappointment" and consequently no article, perhaps?

> expose yourself to critique

Hum, that's interesting. I don't think of "expressing an opinion" as something that "exposes oneself to critique". Maybe I am too accustomed with the idea of "keeping my identity small" and "strong opinions, loosely held", that it's natural to me to differentiate an "attack" on the argument vs the person?

Any chance is this why you are so defensive?

> try to avoid the cross-examination? It's against the rules on HN.

First, not rules but guidelines. Second, you have been responding with passive-aggressive insults and retorts which also makes for unpleasant conversation. Third and most important, there is no cross-examination. I am not challenging your motives or trying to invalidate you as a way to invalidate your opinion. The "prodding" is because I don't think your argument has any merit yet, but perhaps this could change if you provided some underlying reason?

> I've already told you your meta-commentary is unwanted.

It's not lost on me that I when I asked "what you would like to change about python's type hinting without changing the language, and what is wrong about python's type checking that is not just a matter of improving the tool", you completely ignored it and preferred to continue with this grating back-and-forth.

Anyway, you are right when you say it's time to lay this one to rest. I hope the next one gets to be more enlightening to both of us.

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

#579
post #575

Earlier quoted context omitted.

> I don't see what is unreasonable about prodding [...] Yes, I can see that you fail to acknowledge the unreasonability of your prodding. Time to change your tack, maybe voice an opinion of your own, on the actual article, and expose yourself to critique? Maybe drop the condescending tone and try to avoid the cross-examination? It's against the rules on HN. > I do not see what kind of comment we can have except the m…

> 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, maybe engage with the article itself instead of picking on others. It will do you good.

> The "prodding" is because I don't think your argument has any merit yet, but perhaps this could change if you provided some underlying reason?

Surely you can see there's nothing to gain by explaining myself to someone who thinks "my argument doesn't have any merit" (and who doesn't think that's insulting) and who keeps misrepresenting everything I say? I just said something, shared by many others, and you felt triggered by the opinion: that's fine, I don't want to convince you of anything, nor do I feel like being "educated" by you.

> Maybe I am too accustomed with the idea of "keeping my identity small" and "strong opinions, loosely held", that it's natural to me to differentiate an "attack" on the argument vs the person?

Well, you haven't done a good job at it, then!

What do you hope to gain, at this point? Are you waiting for me to "see reason"? That's not going to happen. Surely you see sooner or later dang will intervene here and tell us to shut it down?

re: insulting, passive-aggressive behavior: I re-read our exchange from the start. I was polite, even agreed with you sometimes ("I'm nodding in agreement, why do you think I think otherwise") while your tone kept getting more condescending with each reply, failing to accept my agreements and prodding in what I guess you felt was an "educational" tone. 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? Do you believe the default position of "this argument has no merit, but maybe if this person explains his team's and company's motivations to my satisfaction I might change my mind" is a mindset that is conducive to amicable conversation? I think, if you're honest, you should admit maybe a tiny bit of misbehavior here.

I also read replies you've made in other articles and you seem more reasonable. I'll chalk it up to you not being able to let go at this point, and so you must bite and nitpick at everything I say. I really think you should let it go, make your peace with not being able to convince me of your point of view, and move on to other enterprises.

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

#580
post #149

Earlier quoted context omitted.

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

The TypeScript comparison is on an entirely different axis though, the compiled interpreted one. One of the reasons languages go with the type hinting route is actually to avoid a separate compilation step like TypeScript. That may be totally fine for you (again coming from a statically typed language where this is more or less required), but it’s a hill many are willing to die on. It’s all tradeoffs and design decis…

Agreed it's a different axis, that's why I said "also clashes". I of course think Typescript's choice in this tradeoff was the better one, even though I'm not particularly in love with Typescript either.

At some point everything in proglang is preferences and design decisions, but for me, there are better and worse tradeoffs to make.

Post reply on HN