Python’s “type hints” are a bit of a disappointment to me • Hacker News Board

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

#511

Post by twelve40 » Fri, Apr 22, 2022, 7:01 PM UTC

kortex wrote: post #326

This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling. My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy p…

Definitely types, but it's still weaker than in other languages. Just the other day found a maddening bug, where Django ORM query accepted `date` type comparison against a datetime field, and of course that resulted in crazy things in production. Other languages would have caught this compile-time.

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

#512

Post by twelve40 » Fri, Apr 22, 2022, 7:05 PM UTC

I wonder who, ever, thought that weak typing python- or raw js- style, was a good idea? Come to think of it, is there a single redeeming quality of weak typing in those languages other than "easier to wreak havoc and quicker to write crazy buggy shit"?

There is probably that stoic school of thought that if you are forced to walk around a construction site without a helmet, it will make you a more thoughtful and better worker, but... come on

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

#513

Post by moefh » Fri, Apr 22, 2022, 7:27 PM UTC

woodruffw wrote: post #493

moefh wrote: post #284

Earlier quoted context omitted.

I think you're talking past the comment you're replying to. In both examples, you have tell the compiler exactly what the types are. In the first one you have to cast the return value of `dlsym` to a function pointer, and at that point, as far as the compiler is concerned, it's a function. In the second example you have to explicitly declare the struct containing function pointers, so of course you can call its membe…

I didn't say it was "somewhat untyped." I said it has a very weak static typing system. Just because "weak typing" means something different in Haskell doesn't mean it can't be used meaningfully (and beyond "bad") in the context of C. C's typing is historically referred to as "weak" because C's notion of casting doesn't distinguish between type and value transmutation: pointer-to-pointer casts don't convert the refer…

My point about "weak typing" is this: if someone says "hey, I'm designing a new language, its type system is going to be weak", they gave you no information whatsoever about the type system other than maybe "some people on the Internet will probably complain about it".

That's why it's useless to say things like "it's about as weak as a static typing system can be" and "has been historically considered weak".

If you had explained your objection to C's type system (like you have now), I wouldn't have said anything. And I've been on the Internet long enough to have seen C's typing is historically referred to as "weak" because X for *many* values of X, so I disagree that that's the only or even main objection.

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

#514

Post by plonk » Fri, Apr 22, 2022, 7:28 PM UTC

reikonomusha wrote: post #217

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?

No, you're not the only one. All of these gymnastics to justify the behavior of the string-declared-int baffle me. Is it "legally" baffling, i.e., do I understand why this behaves in the way it does purely mechanically, and do I understand the arguments the gymnasts are making? Yes. But from an idiomatic, colloquial, linguistic, syntactic, programming-historical, or programming-cultural standpoint? Baffled. Even call…

>> Gradual typing is a type system in which some variables and expressions may be given types and the correctness of the typing is checked at compile time [...] > This is definitely not what Python is doing.

When I read "compile time", I mentally replace it with "before runtime". There isn't a real compilation step in Python, so it's reasonable to accept static code analysis as part of "compile time" in that definition.

The point is that type annotations will let a static analysis tool make sure that the program is correctly typed. This can be enabled easily in most of the modern IDEs and editors. You could just decide to block the code's deployment in CI/CD if the type checker raises issues, for example.

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

#515

Post by CraigJPerry » Fri, Apr 22, 2022, 8:13 PM UTC

rwmj wrote: post #473

CraigJPerry wrote: post #445

Earlier quoted context omitted.

Would you be able to share an example of this? I took a random stab in pandas but they’ve adopted type annotations so that defeats the point. So i thought old-school code bases - zope sprang to mind, but that’s not a good example either because they use docstrings and it’s kind of obvious. So i tried gunicorn on a whim and they have even more attention spent on their docstrings. I just want to sample this feeling of…

I was actually looking at urllib3 yesterday trying to work out the return value from HTTPConnection.connect which calls this _new_conn function internally: def _new_conn(self): """Establish a socket connection and set nodelay settings on it. :return: New socket connection. """ ... try: conn = connection.create_connection( (self._dns_host, self.port), self.timeout, **extra_kw ) ... return conn (I've chopped it down a…

When i hover over connection.create_connection i get a docstring that says it returns a socket.

That docstring isn’t enough for the problem you had though, e.g. I wasn’t clear from that if they meant a socket.socket or maybe some special socket derivative type so i hit go to definition and create_connection is a short method - i can see it is indeed a socket.socket being created, configured and returned.

I’m guessing you’re not using any developer tooling, maybe a straight text editor i guess?

This kind of tooling has been around for a long time, i remember using rope and jedi in vim back around the late 2000’s i think. It’s gotten a LOT better since PyCharm appeared mid 2010’s i think - first i recall using it must have been around 2014-ish. These days, it’s even better. I would really strongly encourage adopting some kind of tooling that lets you navigate and has some basic refactoring - rename is usually 80%+ of the value there so it doesn’t need to be complex. A few ergonomics like having the ability to jump to test and call from repl with a keystroke - you’ll turbo charge your comfort and productivity.

That has to be our difference i think because it took one mouse move and one key chord to completely bottom out.

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

#516

Post by the_af » Fri, Apr 22, 2022, 8:19 PM UTC

rglullis wrote: post #508

the_af wrote: post #501

Earlier quoted context omitted.

> "We are going to go back in circles, but as I said in the very first comment: mypy is the tool you want [0]" 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 give…

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

> "What I am having trouble to grasp is [...] why do you keep conflating type hinting with type checking?"

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?

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

#517

Post by CraigJPerry » Fri, Apr 22, 2022, 8:36 PM UTC

oriolid wrote: post #484

CraigJPerry wrote: post #379

Earlier quoted context omitted.

That’s quite a strongly worded opinion. It sounds like it should be utterly trivial in this case to show that typed code causes less harm. I’m happy with whatever definition of harm you’re happy with. So where can i review the data supporting such a strongly worded position?

On a quick search, for example https://link.springer.com/article/10.1007/s10664-013-9289-1 . "This paper describes an experiment that tests whether static type systems improve the maintainability of software systems, in terms of understanding undocumented code, fixing type errors, and fixing semantic errors. The results show rigorous empirical evidence that static types are indeed beneficial to these activities, exce…

Cool - this paper has 3 conclusions:

- Static type systems are an effective form of documentation

– Static type systems reduce the effort to fix type errors

– Static type systems may not be helpful in preventing semantic errors

It would have been awesome to have evidence for #3 but even just #1 & #2 could be useful, albeit to a much lesser extent. Could we quantify by how much?

It’d be important to quantify because if static types mean a developer can be done sooner, then they have spare time to spend improving the software. So do these differences with static types translate into benefits for the developer?

The author of that paper says no. He published this other paper just after that one: https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane...

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

#518

Post by rglullis » Fri, Apr 22, 2022, 8:50 PM UTC

the_af wrote: post #516

rglullis wrote: post #508

Earlier quoted context omitted.

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

> "What I am having trouble to grasp is [...] why do you keep conflating type hinting with type checking?" 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 expl…

> How about both?

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 .

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

#519

Post by _Algernon_ » Fri, Apr 22, 2022, 8:59 PM UTC

bayesian_horse wrote: post #428

notpachet wrote: post #418

Earlier quoted context omitted.

programming languages : diehard dynamic typing advocates :: global pandemic : mask mandate protesters

There is no conclusive and objective evidence that static typing helps at all. Studies are at best inconclusive, certainly a far cry from confirming the superiority of static typing. Everything else is subjective. To have a recent and complete opinion about the one thing you necessarily need to have less of a recent and complete experience with another. The benefits of masks against spreading respiratory viruses are…

https://link.springer.com/article/10.1007/s10664-013-9289-1

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

#520

Post by plonk » Fri, Apr 22, 2022, 9:05 PM UTC

nas wrote: post #170

Diggsey wrote: post #161

Earlier quoted context omitted.

I work on a project that uses type hints but not mypy. To be fair, we used to use mypy, but there was just too much code that it couldn't check (sqlalchemy models, schematics models, some custom models, essentially lots of different data-modelling types!) Maybe it's improved since then, but it just wasn't mature enough at the time. However, type annotations still make the code so much easier to work with, because the…

I've found that it's pretty easy to slowly enable mypy checking. You can mark modules with "type:ignore" to make mypy ignore them. Then, you can move to marking individual statements with "type:ignore". Finally, you can start marking modules with "mypy: disallow-any-generics" at the top. That requires that functions are annotated with types. In a large code base, our team has found type annotations and mypy to be qui…

> You can mark modules with "type:ignore" to make mypy ignore them.

If I added MyPy to the CI/CD checks, some coworkers would flood the code with these to not have to think about their typing. Too bad that some libraries like SQLAlchemy make this mandatory sometimes. I'd like the option to ignore these "type:ignore", but the type system is too immature and has to be overridden sometimes.