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

551–560 of 597 posts

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

#551

Post by kortex »

nine_zeros wrote: post #524
cjalmeida wrote: post #481

Earlier quoted context omitted.

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.

But a language relying so heavily on IDE means that the language is severely lacking. People not using said "modern" IDEs are just stuck out of using the language. Is this progress? Even with modern IDEs, there is a difference between what different IDEs do. So now the language is stuck with different IDEs doing different things. Is the progress? It also means that anyone developing a future IDE can no longer support…

I'm pretty sure the IDE uses either mypy or pyrite under the hood.

I don't know how this is a sign of python lacking. Works just fine in jupyter notebooks, too, and that is hardly an "IDE" (though it does have Jedi autocomplete).

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

#552

Post by rstuart4133 »

john-radio wrote: post #449
tonyg wrote: post #364

Earlier quoted context omitted.

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

And pydantic isn't really about type checking either. In fact it says that in the first few lines of the it's docs https://pydantic-docs.helpmanual.io/usage/models/ :

> pydantic is primarily a parsing library, not a validation library. Validation is a means to an end: building a model which conforms to the types and constraints provided.

Anyone whose used Typescript or even strong typed languages knew what to expect from Python + mypy. No surprises there. But pydantic's use of type hinting to create a remarkably dense serialisation library, and then fastapi's leveraging that to create REST interfaces along with automagic documentation generation - well that wasn't when I was thinking would happen when I saw the type hinting proposal.

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

#553

Post by nmeagent »

wheelerof4te wrote: post #469
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

Yeah, especially types like: List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]] Oh, so I am supposed to make my own data structures now, just for typing? How about no?

LOL, just assign that beast of a type to a name and roll with it:

  Thing = List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]
  
  def foo(t: Thing) -> Thing:
      ...

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

#554

Post by kortex »

ReflectedImage wrote: post #369
kortex wrote: post #320

Earlier quoted context omitted.

What. > Typing encourages a large number of bad coding practices. I'm sorry, what ? What exactly is the bad practice here? Not passing random dicts to my coworkers only to surprise them because the key was userid and not user_id? Or wasting time bugging an overworked dev to ask what their crazy 8 levels of dynamic indirection magic are doing, vs just being able to Cmd-B and step through the code path? > If you can ap…

The bad practice is treating a dynamically typed language as if it was a statically typed language. There are shorter more concise ways to write your programs if you are not using static typing. If you are not writing your Python programs in the Pythonic way then you are not really using Python correctly and you do not get most of the benefits of the language. Unit tests exist for catching bugs in Python. Type hints…

> Typed Python is far more bug prone, why? Because structuring your Python code to support typing means writing considerably more lines of code.

That does not bear out in practice. In my experience, bugs have almost nothing to do with LoC. A short bit of complex, I/O heavy code with lots of state is going to be way more bug prone, and far harder to unit test correctly, than 10x the LoC of purely functional, well-typed, stateless code.

Mutation, parallelism, IO, and complex state space are the four horsemen of the bugpocalypse.

But in fact, I find functional, well-typed, properly abstracted code ends up with less LoC in the codebase, because it's more reusable and composes well.

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

#555

Post by deckiedan »

Bedon292 wrote: post #188
the_af wrote: post #127

Earlier quoted context omitted.

Not my experience!

What speed are you looking for in your CI pipline that you are not getting from mypy? Perhaps you are working on a much larger codebase than I am but the app I use it in takes under a minute. And all the unit tests take longer to run.

A 25k LOC Django project - takes 15-20 minutes to run mypy... Unit tests take about 3 minutes.

That's locally on a fast (ish) laptop. GH CI takes 10 minutes to run tests, so I'm a little hesitant to see how long mypy takes to run.

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

#556

Post by tjoff »

kadoban wrote: post #477
tjoff wrote: post #329

Earlier quoted context omitted.

You don't think that "the author thought that this function would return X, but I got Y" is useful?

Only for archeological, and maybe sometimes psychological investigations of code.

That line of reasoning doesn't make any sense to me.

If the author / last person who touched the code misunderstood it then there is a 100% chance there is a bug here.

Knowing that off the bat is quite helpful. And it also tells something about the code quality if it is a common occurrence.

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

#557

Post by bspammer »

cjalmeida wrote: post #481
nine_zeros wrote: post #427

Earlier quoted context omitted.

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.

I think the difference is largely a culture problem. Most python devs think of typing as a “nice to have” extra, whereas someone using a typed-at-compile-time language see it as an essential feature of good code. You can see the results of this in the fact that a lot of popular 3rd party python libraries still don’t have type hints.

Even with typing, how often do you see Any in python vs Object in Java?

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

#558

Post by ok_dad »

icedchai wrote: post #539
Mehdi2277 wrote: post #360

Earlier quoted context omitted.

My team started with an untyped codebase a year ago. I added a rule to CI that every pr that touches files with type errors must decrease the type errors in touched files by at least 5. When we started we had like 30k type errors. A year later and it’s about 5k left. This was a small wrapper script over mypy/pyright that just called them twice once on master and once on your branch to compare error counts. I did occa…

The problem with these sorts of "rules" is they create needless changes outside of the PR's primary focus. The PR's purpose is to do X: add a feature, fix a bug, whatever. Now because I've done X, you want me to do Y, a set of totally unrelated changes that ultimately are a distraction.

Why wouldn’t you submit two different branches to review? One where you fix errors for types and another for the feature with the fixes:

    (git main) > git checkout -b abc-1234/type-fixes
    
    (git abc-1234/type-fixes) > git checkout -b abc-1234/feature-branch
Then you can submit the feature branch as a PR on top of the type fixing branch and a PR for that branch to main. You only see the type fixing changes on that PR and only see the feature changes on its PR.

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

#559

Post by nine_zeros »

kortex wrote: post #551
nine_zeros wrote: post #524

Earlier quoted context omitted.

But a language relying so heavily on IDE means that the language is severely lacking. People not using said "modern" IDEs are just stuck out of using the language. Is this progress? Even with modern IDEs, there is a difference between what different IDEs do. So now the language is stuck with different IDEs doing different things. Is the progress? It also means that anyone developing a future IDE can no longer support…

I'm pretty sure the IDE uses either mypy or pyrite under the hood. I don't know how this is a sign of python lacking. Works just fine in jupyter notebooks, too, and that is hardly an "IDE" (though it does have Jedi autocomplete).

> I don't know how this is a sign of python lacking

If a language cannot be written or used effectively by devs without IDE, it is an incomplete language.

This has happened in the past is Java. Within a few years, Python will bloat up like Java and everyone will move on to greener pastures.

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

#560

Post by Jcowell »

wheelerof4te wrote: post #469
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

Yeah, especially types like: List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]] Oh, so I am supposed to make my own data structures now, just for typing? How about no?

Seems to me you have a Data Structure problem. What type of data is this suppose to represent and why can a Class not fix it.
Post reply on HN