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

341–350 of 597 posts

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

#341

Post by orf »

neves wrote: post #269
jsmeaton wrote: post #239

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…

Nice. How do you force types just in the new code?

The same (and only) way you’d reasonably be able to do it in any other language that uses a series of text files for an input.

File by file.

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

#342

Post by arinlen »

bayesian_horse wrote: post #290
waitlist wrote: post #285

Earlier quoted context omitted.

I think data science is a perfect example in favor of types -- the code is often terrible because of the lack of typing. Pandas has notoriously poor developer ergonomics, and I recall painfully poring over type errors across the board -- lists, dataframes, numpy arrays, etc. are all iterables, so they can be interchanged in some contexts, but not in others. Had I had MyPy back when I was working in data science, I wo…

What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect re…

> What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding.

I'm not sure if that's true. Doesn't Pandas handle ETL and some anaysis? There is nothing inherent to ETL that makes it a hard problem with compiled languages.

In your opinion, what does Pandas do that's hard to do with compile-time languages?

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

#343

Post by qayxc »

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…

As long as you don't have to rely on 3rd party libraries, sure, type hints are fine.

Many popular libraries, however, don't have type hints or use them inconsistently (looking at you numpy, pytorch, tensorflow, scipy, ...).

Always great fun to see function signatures that use type hints for the parameters and return Any.

So it really depends what kind of code you write - web frameworks might be fine, data science and ML is definitely not.

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

#344

Post by runeks »

> Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime.

I think you mean compile-time and not runtime. There’s not much use in knowing the type at runtime, since it only enables you to print a better error before crashing (“Expected type: x, actual type: y” instead of “AttributeError: 'str' object has no attribute 'append'”).

Types are only truly valuable at compile-time, where they can prevent compilation of invalid code. This is the reason many statically typed languages use type erasure, which removes type information from the compilation output.

In fact, the type-checking phase can happen even earlier than the compilation phase. This is useful e.g. in an IDE, where you care about type errors but not necessarily about running your program.

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

#345

Post by grumpyprole »

bayesian_horse wrote: post #304
smohare wrote: post #300

Earlier quoted context omitted.

If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately. The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re hav…

Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…

You might be more productive in Python versus anything else for the scale and complexity of the software you are involved in, but you cannot make sweeping generalisations like this. I also think you fail to understand that in many situations, static type systems actually improve productivity, especially at scale or for non-trivial domains. This is of course why Python is now trying to retrofit them.

There's also the argument that one is most productive in what they know. As someone who has spent far too long with Haskell and OCaml, Python's semantics and libraries often seem surprising and counterintuitive to me.

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

#346

Post by davidatbu »

I disagree diametrically with both the general sentiment of the article, and every major point that was made in it.

Every point in this blog post strikes me as either (1) unaware of the tooling around python typing other than mypy, or (2) a criticism of static-typing-bolted-on-to-a-dynamically-typed-language, rather than Python's hints. Regarding (1), my advise to OP is to try out Pyright, Pydantic, and Typeguard. Pyright, especailly, is amazing and makes the process of working with type hints 2 or 3 times smoother IMO. And, I don't think points that fall under (2) are fair criticisms of type *hints*. They are called hints for a reason.

Otherwise, here's a point-by-point response, either recommending OP checks out tooling, or showing that the point being made is not specific to Python.

> type hints are not binding.

There are projects [0][1] that allow you to enforce type hints at runtime if you so choose.

It's worth mentioning that this is very analogous to how Typescript does it, in that type info is erased completely at runtime.

> Type checking is your job after all, ...[and that] requires maintenance.

There are LSPs like Pyright[2] (pyright specifically is the absolute best, IMO) that report type errors as you code. Again, this is very very similar to typescript.

> There is an Any type and it renders everything useless

I have never seen a static-typing tool that was bolted on to a dynamically typed language, without an `Any` type, including typescript.

> Duck type compatibility of int and float

The author admits that they cannot state why this behavior is problematic, except for saying that it's "ambiguous".

> Most projects need third-party type hints

Again, this is a criticism of all cases where static types are bolted on dynamically typed languages, not Python's implementation specifically.

> Sadly, dataclasses ignore type hints as well

Pydantic[3] is an amazing data parsing library that takes advantage of type hints, and it's interface is a superset of that of dataclasses. What's more, it underpins FastAPI[4], an amazing API-backend framework (with 44K Github stars).

> Type inference and lazy programmers

The argument of this section boils down to using `Any` as a generic argument not being an error by default. This is configurable to be an error both in Pyright[5], and mypy[6].

> Exceptions are not covered [like Java]

I can't find the interview/presentation, but Guido Van Rossum specifically calls out Java's implementation of "exception annotations" as a demonstration of why that is a bad idea, and that it would never happen in Python. I'm not saying Guido's opinion is the absolute truth, but just letting you know that this is an explicit decision, not an unwanted shortcoming.

[0] https://github.com/RussBaz/enforce

[1] https://github.com/agronholm/typeguard

[2] https://github.com/microsoft/pyright

[3] https://pydantic-docs.helpmanual.io

[4] https://github.com/tiangolo/fastapi

[5] https://github.com/microsoft/pyright/blob/main/docs/configur...

[6] https://mypy.readthedocs.io/en/stable/config_file.html#confv...

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

#347

Post by IshKebab »

ActorNightly wrote: post #119
IshKebab wrote: post #28

Yeah they're pretty bad but they are still better than nothing. If you are in the unfortunately position of having to use Python I would recommend using them. I would also strongly recommend using Pyright (the default checker in VSCode) over MyPy. It's so much better, and the author is really responsive on Github. But yeah, in general trying to use type hints in Python is like trying to discuss philosophy in a mental…

The whole reason Python and JS surpassed most all other languages is specifically because you can write code fast, without worrying about strict definition of data structures. The issues with python code bases aren't from a lack of strict typing or type support, but from a lack of a good testing framework.

JS is popular because it's literally the only language web browsers support.

Python is popular because it's very beginner oriented, so it's the first language a lot of people learn. It's modern BASIC.

Neither of those things mean that writing dynamically typed code is a good idea. The idea that you can write dynamically typed code faster isn't even true once you get past a couple of hundred lines.

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

#348

Post by gorgoiler »

lolinder wrote: post #205
gorgoiler wrote: post #162

I never liked how go makes you fix all your types before letting you run a program. Suppose I wanted to hack something up and run it, just as a new idea? Maybe change a library function that is called in 20 places, but I only want to test it in one call site. Nope! Go forces you to polish up your turd of an idea in all 20 call sites before you can see that your algorithm / model / refactoring is nonsense. If you back…

There's a big difference between Python's types and and Go's: in Python they're only there to check correctness while in Go they're there to tell the compiler how to lay out the machine code. If the compiler ignored types in Go it wouldn't just throw an error message at runtime, the behavior would be completely undefined.

That’s interesting.

The hacky-developer option I’m after is the ability to cull pieces of code if they do not type check, I guess.

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

#349

Post by bayesian_horse »

arinlen wrote: post #342
bayesian_horse wrote: post #290

Earlier quoted context omitted.

What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect re…

> What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. I'm not sure if that's true. Doesn't Pandas handle ETL and some anaysis? There is nothing inherent to ETL that makes it a hard problem with compiled languages. In your opinion, what does Pandas do that's hard to do with compile-time languages?

I didn't say "with compile-time languages" but "with compile-time type systems". And many similar tools in a statically typed language will necessarily create a way to have one static type that doesn't care what the data inside actually looks like.

This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor. Worse, most often you don't know (or want to know) some of the dimensions or even dimensionality of some of the objects. Then it is impossible to check all of this at compile time.

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

#350

Post by heavyset_go »

reikonomusha wrote: post #243
woodruffw wrote: post #241

Earlier quoted context omitted.

Type hints are not static type declarations. Python does not refer to them as such, nor does Mypy or any other typechecker for Python type hints. Absent of active machine checking (e.g., via mypy), type hints should be considered exactly what you said: another form of documentation, one that might just be wrong.

This is my point precisely: it looks like a static type declaration to anybody who has seen what a static type declaration looks like in any statically or gradually typed program in the last 50 years. But in Python, it's not (and documented in a PEP as not), and it causes massive confusion.

That's the way it works in Ruby with RBS, and it will work the same way in JavaScript should Microsoft's proposal for type hints make it into ECMAScript[1].

[1] https://devblogs.microsoft.com/typescript/a-proposal-for-typ...

Post reply on HN