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

481–490 of 597 posts

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

#481

Post by cjalmeida »

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.

As many already said, 99% is just a modern IDE with a one-click-install plugin.

Also, I don't know the grip with productivity tools.

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

#482

Post by cjalmeida »

nine_zeros wrote: post #470
Spivak wrote: post #459

Earlier quoted context omitted.

Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.

My codebase is more complex than str, text, dict, int, bool. So developers are creating complex custom types with union[custom_type_1, custom_type_2] where each custom type could have more unions of other custom types. These custom types then get imported everywhere. It is utter garbage.

You know you can use type aliases, right?

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

#483

Post by tpoacher »

All the problems the author seems to have seem to be problems of "false expectations" rather than type hints lacking value per se.

In which case, I fully declare, publicly, that I am very disappointed with numpy, because it doesnt have good coffee making facilities out of the box.

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

#484

Post by oriolid »

CraigJPerry wrote: post #379
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.

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, except when fixing semantic errors." is pretty much as strongly worded as scientific journals can accept.

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

#485

Post by cjalmeida »

eweise wrote: post #475
Spivak wrote: post #460

Earlier quoted context omitted.

Because ecosystems are what makes people productive and languages are just a means to access them. Python's ecosystem is absolutely massive and high-quality.

Most popular languages have massive ecosystems. Don't see Python's being a differentiator except for a few specialized areas. In fact, the project I'm on runs on spark wrapped by python libraries, so really its the scala libraries that provide all the heavy lifting.

We use Spark extensively. We also use @pandas_udf to run some part of our Spark pipeline through some Python-only ML libraries.

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

#486

Post by mountainriver »

wheelerof4te wrote: post #474
animal_spirits wrote: post #471

Earlier quoted context omitted.

If you find that you are returning silly types like that, then it is an indicator you are writing your function badly and should refactor it to be simpler

That's not a silly type, it is just a silly type annotation. It's easy to unpack the tuple inside that list. What is not easy is type-hinting it. What if I want it to be both an list and an iterator? Well, I would have to use Union. I'll leave it to you to write that Union "type".

yeah it speaks to your ability to create code people can understand, that doesn't change with types, they just illuminate it

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

#487

Post by mountainriver »

bayesian_horse wrote: post #289
mountainriver wrote: post #233

Earlier quoted context omitted.

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

Have you tried it? Python has gained most of its popularity before type hints, and I would (wildly) guess 99% of Python programmers don't even use type checking at all. Static typing is completely viable and I hear those arguments mostly from those who didn't use Python for a long time. The added productivity makes up for a little more debugging while the program is running. I'd also posit that many Python codebases…

I have absolutely tried it and worked on many code bases big and small before typing happened. I've also worked on other languages and paradigms and seen what works and doesn't.

In my experience its the other way around. Most people who are a fan of dynamic typing have worked in systems with types. The world is largely coming around to the view that types make more consumable and safe software

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

#488

Post by mountainriver »

waitlist wrote: post #285
mountainriver wrote: post #233

Earlier quoted context omitted.

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

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…

Totally agree, I would love for data scientists to use types and a lot of other good practices. I work primarily in mlops and have been trying to do this for some time, it just mostly feels like a losing game.

The output of most analytics is a report. For longer lived processes it seems easier to just hand off

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

#489

Post by wheelerof4te »

oriolid wrote: post #480
wheelerof4te wrote: post #444

Earlier quoted context omitted.

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.

> Otherwise, write your own equivalent. And be judged for wasting time reinventing a wheel?

Hey, it is still your wheel, built according to your use-cases.

That is never a waste of time.

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

#490

Post by wheelerof4te »

mountainriver wrote: post #486
wheelerof4te wrote: post #474

Earlier quoted context omitted.

That's not a silly type, it is just a silly type annotation. It's easy to unpack the tuple inside that list. What is not easy is type-hinting it. What if I want it to be both an list and an iterator? Well, I would have to use Union. I'll leave it to you to write that Union "type".

yeah it speaks to your ability to create code people can understand, that doesn't change with types, they just illuminate it

I, too, can write code that everyone understands! Behold it's beauty:

  Union[List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]], Iterator[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]]
/s
Post reply on HN