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

441–450 of 597 posts

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

#441

Post by wheelerof4te »

gilbetron wrote: post #415
bayesian_horse wrote: post #304

Earlier quoted context omitted.

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…

On the small scale, Python is very productive. Once you get to large codebases with a rotating roster of many developers, it becomes a net negative, which is why type specification languages are gaining major inroads. I love Python, but I wouldn't write anything for production at any scale in it anymore. But for small scale stuff, it remains my favorite! (Although, I like static binaries languages, like Go, for a lot…

How is typing productive in large codebases? If I see a bunch of imports related to typing only, I have to juggle them around in my mind together with stuff that really matters.

Not to mention the notorious circular import problem, that is much more likely in a big codebase.

If I have a custom class, that class has to be passed as a type hint for functions. What If I use that class in another module, but have to import it inside this one that has a type-hint only?

Well, let me introduce you to their genious solution:

  from _future_ import annotations
  from foomod import FooClass

  def myfun(foo: FooClass):
    return foo.bar()
Wonderful, isn't it?

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

#442

Post by eweise »

mountainriver wrote: post #233
linsomniac wrote: post #180

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…

Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work

Totally agree. I'm on a project using python for the first time and really can't believe how horrible it is to not have type checking, especially given that it takes time to run the code as a glue job.

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

#443

Post by TomBombadildoze »

Humphrey wrote: post #118

While I love the idea behind Python's type hints, they are merely a shadow of the success of TypeScript. Like the author, I've mostly given up on adding type hints in my Python code. I now only use them when I want to help my IDE find autocomplete suggestions. Whereas TypeScript was a game changer for JavaScript. I used to hate JavaScript, but somehow TypeScript has become one of my favourite languages! How has the a…

There are many complaints in this discussion about inaccuracies in the post but you've actually captured the essence of the problem--type hints just don't solve the problem well.

My team began using type hints and aggressively applied mypy to new code starting a couple years ago and it _has_ helped immensely. However, we also started doing some work in Typescript around the same time and the difference in developer experience and code quality is pretty clear. Typescript is just a better solution to the problem of adding type information to a dynamic language.

What's especially frustrating is living through the design and early life of asyncio (Guido, you should have adopted the gevent model), then getting excited about typing, only to find it is also not very good. What's _especially_ frustrating is that Typescript existed two years before PEP 484 was published, so the core developers had ample time to seek inspiration elsewhere, and they came up with a sub-standard solution.

Python needs a Typescript analogue, with a compiler that targets vanilla Python.

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

#444

Post by wheelerof4te »

rwmj wrote: post #362
bayesian_horse wrote: post #304

Earlier quoted context omitted.

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…

The number of times I've stared at some random Python function deep inside a library wondering what does this function return ? Even the docs often don't say.

Well, the author of that undocumented function maybe did not mean for it to become widely used.

There are a lot of "libraries" people write for their use only, who then put them on Github as a token of good will.

You as a user of someone else's library can either contribute to it or learn to use it. Otherwise, write your own equivalent.

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

#445

Post by CraigJPerry »

rwmj wrote: post #362
bayesian_horse wrote: post #304

Earlier quoted context omitted.

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…

The number of times I've stared at some random Python function deep inside a library wondering what does this function return ? Even the docs often don't say.

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 lost confusion in python so that i can figure out how I’d deal with it.

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

#446

Post by eweise »

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…

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

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

#447

Post by wheelerof4te »

qayxc wrote: post #343
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 an…

Type hints are good if you stick to the std + your own code that mostly relies on std.

Otherwise, don't bother.

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

#448

Post by wheelerof4te »

nine_zeros wrote: post #427
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…

Python types just work. Just use these 30 libraries, spice up your IDE with settings and voila /s. This is garbage and moving backwards as a programmer. I loved python when it was easy to use with any editor and with few plugins. Now I'm just going to switch to a statically typed language where I don't have to install a zillion plugins to get first class typing.

This is the crust of the problem.

Python type-hints bind you to a lot of other sister projects of Python, which makes you question if they are even official addition to the language.

I think that's also what the OP's article tries to convey.

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

#449

Post by john-radio »

tonyg wrote: post #364
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…

> My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks. Christ. What a mess. With a stack like that, it's a stretch to say you're "writing in Python" anymore.

I think the person you're responding to is just trying to be thorough in case it is helpful to someone else setting up python tooling; the only parts of what they wrote that are relevant to type checking are mypy and pydantic.

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

#450

Post by Spivak »

np_tedious wrote: post #186
linsomniac wrote: post #180

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…

> I'm not even using mypy often, if ever. Hopefully your CI does?

It's not really as necessary as you think -- making mypy/pyright pass your CI ends up being a lot of busy work to make the type checker happy when, to me, all the value is realized when it's used as a development aid. If your test suite passes that's honestly more than good enough.
Post reply on HN