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

421–430 of 597 posts

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

#421

Post by bayesian_horse »

bostik wrote: post #407
NumberCruncher wrote: post #382

Earlier quoted context omitted.

> That doesn't mean an experienced full stack developer would do Data Science better, because he might lack a lot of skills that matter more in that domain. This resonates with my experience. I had the opportunity to work on a DS codebase written entirely in Scala with all the typing, parallelism, actor model, whatnot. Basically I joined the company because of this technical factor. It was fun until I figured out tha…

> integration tests running on real data not on mokups. I can see you are enjoying the life outside of a highly regulated industry. Having certain kinds of production data in tests (or feeding that to test environment) would be a major audit finding in any finance or healthcare company. Makes for both a blessing and a curse.

You can anonymize such data or get the necessary agreements for a small subset. All of which is tricky, but not impossible.

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

#422

Post by bayesian_horse »

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

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

#423

Post by bayesian_horse »

krageon wrote: post #380
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?

You can review it by talking to people that inherit your code, especially if they're still acclimating to it :)

So you don't have any hard data either...

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

#424

Post by NumberCruncher »

bostik wrote: post #407
NumberCruncher wrote: post #382

Earlier quoted context omitted.

> That doesn't mean an experienced full stack developer would do Data Science better, because he might lack a lot of skills that matter more in that domain. This resonates with my experience. I had the opportunity to work on a DS codebase written entirely in Scala with all the typing, parallelism, actor model, whatnot. Basically I joined the company because of this technical factor. It was fun until I figured out tha…

> integration tests running on real data not on mokups. I can see you are enjoying the life outside of a highly regulated industry. Having certain kinds of production data in tests (or feeding that to test environment) would be a major audit finding in any finance or healthcare company. Makes for both a blessing and a curse.

What I wrote was meant in the context of data science. You can not do ML without having access to real data, not even in highly regulated industries. Obviously you won't touch PIIs. But whether the real data is sitting in your train/test/validation data set or you use it for integration tests, doesn't make any difference from the perspective of an audit.

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

#426

Post by lolinder »

bmn__ wrote: post #370
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…

> Is there a “hey ho your types are all out of sync but let’s try and compile anyway” option? "typed holes" in some programming languages

Typed holes are slightly different: they allow you to write the types but not the code.

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

#427

Post by nine_zeros »

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.

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

#428

Post by bayesian_horse »

notpachet wrote: post #418
krageon wrote: post #368

Earlier quoted context omitted.

If you write more code that is untyped than typed, you are harming whoever comes after you. Untyped code is an absolute dragon even if it is properly documented (which it practically never is). Glorifying "productivity" and putting it above the greater good is essentially everything that's wrong with the world, at every level.

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 easily and objectively proven. Completely different thing.

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

#429

Post by bayesian_horse »

analog31 wrote: post #410
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…

In my view it's both. I'm one of those "scientific" programmers. I've used type hints, just to learn it, but tend not to use them in practice. Bugs caused by typing errors seem to be extremely rare in my little world. I've also programmed extensively in Pascal, assembly, and C. I get it about types. Don't forget C has 8 different types of integers that have to be kept straight. ;-) On the other hand, I realize that a…

If you have programmed extensively in Pascal, assembly and C, you aren't "one of those scientific programmers". Or at least not the newer generation that got started on R, Python and maybe SAS...

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

#430

Post by jghn »

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…

> make things possible, often just to run it once

This is the largest difference. When there's no expectation of code lasting beyond a very short lifespan, why go through the effort to future proof things, improve maintainability, have better ergonomics, etc?

Post reply on HN