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

381–390 of 597 posts

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

#381

Post by avianlyric »

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.

To be fair, I don’t think you need that entire stack. Just using VSCode + pyright (which is a one button install in VSCode) + type stubs for libraries your using without native hints, gets you 99% of the benefits.

If you really want, you can even throw in a little pre-commit hit hook that runs pyright and prevents you from commuting code with type errors.

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

#382

Post by NumberCruncher »

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…

> 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 that DS was "typed IF-THEN-ELSE written by Java devs in Scala returning stuff the users complain about with high reliability within milliseconds". Now I am happy to be back to the single threaded untyped Python world. Still no bugs in production, because we validate all requests to death, have unit tests and integration tests running on real data not on mokups. Basically we follow the principle: if the integration test passes, our typing is just right, or at least good enough. Funnily all the typing errors we catch are caused by wrongly typed data, coming from the productive system written in a typed programming language... what a strange world.

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

#383

Post by danmur »

serial_dev wrote: post #376
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.

> Most of their main arguments (...) evaporate as soon as you start using the correct tooling. You silly! Just use these carefully curated list of 28 different tools (that I got to after years of trial and error) and you'll have a somewhat acceptable tooling and type support in Python.

Anything that can use an LSP server will give you most/all of those benefits. Your favourite editor + LSP, that's the tooling. It's very much worth it.

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

#384

Post by Loeffelmann »

goodoldneon wrote: post #257
Frotag wrote: post #132

Earlier quoted context omitted.

This is exactly my experience. I've also found that Python's type annotations for even basic stuff like are way clunkier to write. For example an optional requires a typing.Optional import or a an ugly "| None" instead of a question mark like TS has. And good luck trying to annotate some complex / nested json, you'll need a bazillion intermediary classes.

There's a subtle difference between TS' question mark and union. The question mark means "this argument is optional", which can be different than "this argument can be undefined". The following code is valid: function foo1(value?: number) {} foo1() But the following code will raise a type error: function foo2(value: number | undefined) {} foo2() In practice, that rarely becomes problematic. But it's good to know the…

I really think the second one shouldn't raise a type error.

This is already invalid:

  function foo1(arg1?: number, arg2: number) {}
In that case you have to use

  function foo1(arg1: number | undefined, arg2: number) {}

  foo1(undefined,1);
But other than that what is the use case?

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

#385

Post by ramraj07 »

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.

Wow gatekeeping types out of python are we? Of course the language looks different when typing is enforced, let it evolve.

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

#386

Post by ramraj07 »

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…

Have you tried pytype? Curious if anyones compared it properly To mypy.

Otherwise the exact same stack as yours, we use fast api as well. Also a big fan of using dataclasses everywhere.

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

#387

Post by faho »

tonyg wrote: post #365
hermitdev wrote: post #88

Earlier quoted context omitted.

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature. In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic t…

> One doesn't know the real type of a variable until runtime. In the program def x(f): return f(3) what is the "real type" of `f` at runtime; say, at the instant just before the call to `f`? How can you tell? If your answer is that `f` has type "function-like", then that's a much weaker kind of a type than even type hints offer, let alone a real type system.

> what is the "real type" of `f` at runtime; say, at the instant just before the call to `f`? How can you tell?

We can tell by looking at what python triggers TypeErrors for.

>If your answer is that `f` has type "function-like", then that's a much weaker kind of a type than even type hints offer, let alone a real type system.

f implements the Callable interface - meaning it's either a function/method or an instance of a class with a `__call__` method.

So you can pass e.g. `print` or an object with a `__call__` method. If you try to do `x(5)` that's an immediate runtime TypeError because `5` can't be called.

f must also accept one int argument. It can have additional optional arguments, and it can also accept other types (e.g. `f("foo")` can also work!), but it must work on one int. The one int can already be optional - the function can also work with zero arguments.

Calling e.g. `"foo".join(5)` fails with a TypeError because 5 isn't Iterable, and calling `"foo".join([1], [2])` fails with a TypeError because it gets more arguments than expected.

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

#388

Post by dgan »

CrLf wrote: post #375
dgan wrote: post #372

Landing in a large-ish python project without type annotations is a pain. Author says that he won't use type annotations because they "can be wrong", well, you only rely on variables names and documentation for that, you have even less chance to get that right. Is that "line" variable a "LineInvoice" or "InvoiceLine" (yes, two different classes) ? Oh, right, both can be used in this place exclusively because one is s…

Python's base philosophy is duck typing. Whenever I read complaints like this the root cause is almost always trying to turn Python into something that it isn't instead of embracing what it is (if this isn't feasible, then Python is the wrong choice). Programming in Python worrying about types instead of behavior reminds me of the quote "you can write FORTRAN in any language".

Well, the problem is more often than not, I am an employee. I won't come to a company and tell them "you have been using that wrong".

So while correct, your statement is void of any actionable advise

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

#389

Post by cttet »

tootie wrote: post #254
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…

I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.

If the type system is not powerful enough it will be extra works just to get around the inadequacy.. If c# have some support of sum type and structural subtyping like Python I will be using that... I mean even Haskell does not have proper records.. Python is not definitely the best, but quite nice among the current options.
Post reply on HN