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

431–440 of 597 posts

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

#431

Post by smallerfish »

bayesian_horse wrote: post #417
smallerfish wrote: post #392

Earlier quoted context omitted.

You wouldn't typically type tabular data in any language. Give it (at most) a DataFrame type if you must, where StoreTransaction describes the structure of a row - maybe declaring only columns that model generation code was doing typed operations on (e.g. numerics vs strings) to avoid the need for reflection.

Either you type the tabular data at compile time or you don't get type checking of tabular data at compile time. The number and types of the columns aren't necessarily known at compile time. Which leads to runtime errors. Even in a statically typed language, such dataframes are a kind of "dynamic typing escape hatch". As complexity of a software increases, such mechanismus of dynamic typing and throwing runtime error…

Sure. If you're dealing with untyped data at runtime you can't type it at compile time. Not a new issue, and handled all the time in otherwise typed languages.

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

#432

Post by j4mie »

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…

What's your definition of "large codebases" here? My experience is that on Python codebases large (~100k lines) and small, type annotations are generally a net negative, particularly with a "rotating roster of many developers", because of their complexity and detrimental effect they have on readability. As the OP says, incorrect types are worse than no types at all.

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

#433

Post by icedchai »

bayesian_horse wrote: post #422
gilbetron wrote: post #415

Earlier quoted context omitted.

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…

What is "major inroads"? Python is actually rising in popularity and major companies are building big things entirely in Python... In my opinion there is no excuse not to.

Major companies build things entirely in Javascript, too. Popularity doesn't mean anything. Honestly, for a small web app, I'd pick PHP / Laravel over Python. Deployment is way simpler.

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

#434

Post by pvillano »

totony wrote: post #183
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…

>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. I agree this is useful, but to me the most useful feature of types are the self-documentation. It's crazy the difference between a non-typed library with shitty documentation vs a typed library with shitty documentation.

type hints are documentation, and machine readable documentation to boot!

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

#435

Post by foepys »

bayesian_horse wrote: post #422
gilbetron wrote: post #415

Earlier quoted context omitted.

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…

What is "major inroads"? Python is actually rising in popularity and major companies are building big things entirely in Python... In my opinion there is no excuse not to.

What you both are experiencing is your bubbles clashing.

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

#436

Post by nerdponx »

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.

That's such a disingenuous argument.

First of all, Black and Isort are literally code formatters that have nothing to do with type hints.

Second, the whole point is that you can actually develop powerful dev tooling for Python now, whereas in the past it was difficult or impossible.

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

#437

Post by the_af »

ossopite wrote: post #416
the_af wrote: post #98

Earlier quoted context omitted.

Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.

pyright is a command line program https://github.com/microsoft/pyright in my experience it's a far better type checker than mypy, which tends to silently not check things without you ever realising

Thanks for the suggestion! I didn't know this checker existed. Will definitely try it.

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

#438

Post by bredren »

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…

I used tabnine from early on but found its capability pretty well subsumed by GitHub copilot.

What has kept you on tabnine?

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

#439

Post by notpachet »

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…

Well, while you're waiting for that study to ride down from heaven on a white horse clad in gold, the rest of us are going to just quietly get on with being (subjectively) more productive.

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

#440

Post by stackedinserter »

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…

What opensource project is closest to "doing python the right way", in your opinion?

I'm in "python is not suitable for production" camp, would be happy to change my mind.

> I remember the dark ages, before type hints. It was rough. I lived in the REPL. Write 3 lines, run, Exception. Write 3 more lines, run, NoneType error.

That's why I switched (back) to typed compiled languages and never went back.

Post reply on HN