Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.
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 am often reminded of my perl days, where something I thought idiomatic 3 days ago, is now completely incomprehensible when I just want to make a minor change)
It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).
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.
If you/your team want to use a statically typed language, then use one. Python is not it.
Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job.
This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't.
This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though.
> If you/your team want to use a statically typed language, then use one. Python is not it.
This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?
> it just doesn't work cleanly out of the box like in true statically typed languages
So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.
I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them.
Also, let me restate we cannot pick the language. We can just make better or worse use of it.
That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments.
> We can improve the tooling and train the team with better practices though.
"Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it. You can look at your past burn charts and say "look at this bug here, what caused and why did it take so long to fix? Is this the type of problem that would be easier to solve with static analysis of the code? Look at this refactor that we are planning for next quarter, should we try to increase the test coverage to make sure we have more confidence in the changes?"
Let me give you a twofold answer to this.
1. I do think statically typed languages are generally better than dynamic languages for most use cases (with a few exceptions). I don't expect to convince you or anyone else of this. It may even be the case that I'm mistaken about this, but I made my mind after years of experience with both kinds of languages.
2. The alleged hidden assumption is not truly important. One should always criticize flawed features of any language, static or dynamic, and the answer should never be "well, choose another language". How else will languages improve if nobody is working on addressing their pain points?
> "Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it.
I'm both nodding in agreement and finding it very hard to think of something I said that made you think I disagreed with this.
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, but my experience tells me that hydroplanes are faster. I tried putting wings on my motorboats, but it still wasn't as fast. No, we can not buy hydroplanes. No, my team is not licensed to fly. But if no one acknowledges that motorboats are slower, how will they ever be as fast as a hydroplane?
And no, I haven't really looked into the fuel costs of planes vs boats..."
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?
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?
I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.
But given that your response to the mypy recommendation was to complain (it's slow, it doesn't catch everything) then it makes it difficult to acknowledge the "valid criticism"... as in: people are working on it, what else do you want?
[0] https://mypy.readthedocs.io/en/stable/existing_code.html
What makes you think I'm not using mypy, or that I didn't read the article you linked to or follow its guidelines (which are very sensible)?
In your mind, is it the only possibility when someone criticizes a tool that they are "using it wrong" (to paraphrase Steve Jobs)? No other possible reason?
> "But given that your response to the mypy recommendation was to complain (it's slow, it doesn't catch everything) then it makes it difficult to acknowledge the "valid criticism"... as in: people are working on it, what else do you want?"
Given that I didn't say or imply that I don't believe there are people working on improving mypy and Python type hints, "what I want" is merely to support the article's assertion that the current version of type hints Python provides is confusing and not very good.
Please, for the love of all that is holy, don't recommend to me again that I switch to a different language. That's not how this works.
What I am having trouble to grasp is: if you understand that Python is not a statically typed language, and if you claim that you do not want to "turn" Python into such, why do you keep conflating type hinting with type checking?
They are two separate things. That is the nature of the game. Do you have criticisms about limitations from mypy, fine, but then you are not talking about issues with type hinting but merely the type checker tool.
It's not my business to help you with your trouble grasping things, but why do you think I'm conflating type hinting with type checking? I specifically asked in this comments section what type hinting meant if not what I thought, and was told by several people "it's just standardized comments", which I then explained was unsatisfying (and other people agreed with me).
> "you are not talking about issues with type hinting but merely the type checker tool"
How about both?
Let me suggest you a more productive use of your time: address the article's complaints as a top-level comment (which I see you haven't yet). I suppose you're more interested in the article's topic than in correcting my alleged misconceptions?
Because the "issues" with type hinting that you are talking about are only based on what you wished it was, not on what it is or what it could become!
Ask yourself this: what about the python's type hinting story you think could be improved without turning python into a statically typed language? What about the python's type checking story that is missing or broken and that is attributable to the language and not to the tool?
> I suppose you're more interested in the article's topic.
Quite frankly, no. My motivation for the conversation now is mostly to see how long is going to take you to realize that you are merely wishing that your motorboat could fly like a hydroplane. It's not about "misconceptions", it's about you complaining about something not meeting your unfounded expectations .
Oh, I see. Well, I have no interest in that kind of conversation.
Goodbye.
What I am trying to say is that perhaps the lesson you could take from this it's to not think that something is "inferior" or "needs fixing" just because it doesn't immediately meet your expectations.
It isn't Python's fault that you have to use at the job even though you don't like it.
It isn't Python's fault that you have to use even though you are absolutely certain that dynamically typed languages are worse.
It isn't Python's fault that type hints are just hints and can not become a full-fledged type system.
It isn't Python's fault that mypy is still not mature enough to work reliably for you.
And it certainly isn't Python's fault that your coworkers don't care about all that as much as you do.
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!
Anyway, you also had the chance to respond to other questions I made, but instead you preferred to stick to defensive retorts.
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.
> 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.
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.
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.
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.
> 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.
Oh. My. God.
A Socrates complex.
I give up.
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.
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)
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!).
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.
If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.
In my opinion, of course.
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.
Useful, but way less useful than if it was actually checked.
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.
I wish this was the case with command line tools I can plug into the build/deploy pipeline. I know they exist, it's just they are unsatisfying and there are lots of cases where they miss stuff that is trivial to catch in statically typed languages.
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 sometimes split into a separate tool).
Besides, your IDE doesn't live in the build pipeline (in your CI/CD tool). So you cannot rely on it.
A type hint would have answered their question immediately (as they were reading the code).
An unenforced type hint is just like any comment: likely to get out of sync with the code, and a human must do all the work of keeping it up to date.
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 can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.
Do either of these things do anything comments couldn't? Not really. But they're ways of indicating intended semantics without formally documenting your stuff, and when most of what you use the language for is scripts, that's actually pretty helpful. People actually use type hints in a way they didn't with comments, and that's caused a major improvement in code readability. Or at least that's been my experience
You can absolutely look at all this and say python's a crazy, terrible language you never want to touch, but if you've got no choice on language for whatever reason, or you're throwing something together and don't feel like writing `private static final synchronized` forty time, type hints are great.
> 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.
Which is what type checking should be all about, right? Preventing accidental misuse?
> 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 can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.
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. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me...
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.
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.
At some point everything in proglang is preferences and design decisions, but for me, there are better and worse tradeoffs to make.
So for that List[int] example, you probably want to take a(n) Iterable[int], Iterator[int], or Collection[int] instead, depending on exactly how you use it.
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.
You seem to be describing actual type checking, which I understand (though in my opinion, mypy is not a satisfying tool for this).
I think mypy has to let some potential errors through because otherwise it would spew 1000's of spurious error messages on perfectly good, unannotated legacy code. Something similar happens with the Erlang dialyzer. The same thing applies to tools like Coverity, that aim to find potential bugs in legacy C code.
You could instead imagine a version of mypy that makes no concessions at all to legacy code, and insists that your code be 100% free of type errors, even if that means that some older constructs and styles no longer work. Would that be a good thing? Probably not: we have Haskell for that. Mypy's leaking errors is probably a practical necessity in retrospect. But, I wasn't expecting the leakage, so it surprised and disappointed me when I encountered it. I had thought I was getting something more like Haskell. Mypy still has attractions, but it's less great than I had hoped.
Type hints (with mypy) aren't going to save you from becomming a bad programmer. But they _do_ help you become a better one!