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

521–530 of 597 posts

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

#521

Post by joshuamorton »

reikonomusha wrote: post #219
woodruffw wrote: post #156

Earlier quoted context omitted.

> In what reasonable sense can Python be said to "enforce types at runtime" here? Python is both strongly typed and protocol-typed. In the case of `print(...)`, the protocol is that the received parameter responds to `str(...)` (i.e., has `__str__`). (What Python isn't is statically typed. But "strong" and "static" are completely different typing dimensions.)

I think the person you're responding to means to ask > In what reasonable sense can Python be said to "enforce statically declared types at runtime" here? which is certainly an extremely pertinent question for a language that allows declaring supposedly static qualities of a program.

What other languages do that though? C doesn't, Java doesn't outside of particular cases. If you can trick or mislead the compiler, the runtime often has no type information at all, so you'll get, at best, a ClassCastException, and more often than not get a segfault.

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

#522

Post by joshuamorton »

reikonomusha wrote: post #248
woodruffw wrote: post #246

Earlier quoted context omitted.

> If your statement were absolutely true then a product like mypy would neither exist nor provide value. I don't see why that would be the case. The value of Mypy is that it's essentially a proof language over something that resembles Python[1]: it's a way to do some amount of static typing without having to maintain a separate copy and representation of the program. And sure: Python could detect inconsistent type hi…

> Python could detect inconsistent type hints at runtime. But why would it? Because the programmer explicitly intended a contract which is being violated, which would in turn indicate a bug.

Do you think other languages should do the same, because very few do any kind of runtime type checking (e.g. bounds checking) due to the performance penalty. Why focus specifically on python's lack of runtime type checking?

Anecdotally, my code in python is functionally fully typechecked and runtime type checking would solely penalize me by slowing down my code. There's no need for it because the type checker correctly proves the soundness of the program's types, in exactly the same way that Java's or C++'s do.

The point is precisely that you don't need to suffer the costs of runtime type checking if you have a solid typechecker. Lisp's approach here is worse than the one adopted by python/js/ts/go/etc.

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

#523

Post by tonyg »

faho wrote: post #387
tonyg wrote: post #365

Earlier quoted context omitted.

> 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 o…

Right, "function-like". I thought OP was meaning the static type of a variable, which genuinely can't be known fully at runtime in general. But it turns out that they meant to write "... until runtime", not "... at runtime", which makes this all a bit moot. And invites more confusion about the two disjoint usages of the word "type" in the PL community, as seen liberally spattered about elsethread, but that can't be helped :-)

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

#524

Post by nine_zeros »

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.

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 these languages without support. Is this progress?

God forbid someone tries python on a new architecture where new the entire complex toolchain is not going to be available. They just can't use this language. Is this progress?

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

#525

Post by nine_zeros »

cjalmeida wrote: post #482
nine_zeros wrote: post #470

Earlier quoted context omitted.

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?

So now you are going to create complex types and then create aliases for them? What are we even developing at this point?

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

#526

Post by icedchai »

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

How is typing productive in large codebases? If I see a bunch of imports related to typing only, I have to juggle them around in my mind together with stuff that really matters. Not to mention the notorious circular import problem, that is much more likely in a big codebase. If I have a custom class, that class has to be passed as a type hint for functions. What If I use that class in another module, but have to impo…

I also find most of the "import typing" stuff to be clutter. I worked at a place that was heavily into adding typing to existing code, some of which was almost a decade old. They spent more than a few person years on that effort, and it's still going on.

Not once did I find the additional typing useful in my actual day-to-day work.

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

#527

Post by mmcnl »

I actually enjoy the typing in Python. The only problem is lack of support from third-party libraries. I find myself fighting the typing errors so often by adding: # type: ignore. Especially pandas gives so many errors. Type hints are included but they are often just plain wrong.

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

#528

Post by icedchai »

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?

Yep, that's gross. Having come from a position where people where forced to actually add typing like this to make it through code review, I feel the pain.

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

#529

Post by icedchai »

Spivak wrote: post #450
np_tedious wrote: post #186

Earlier quoted context omitted.

> I'm not even using mypy often, if ever. Hopefully your CI does?

It's not really as necessary as you think -- making mypy/pyright pass your CI ends up being a lot of busy work to make the type checker happy when, to me, all the value is realized when it's used as a development aid. If your test suite passes that's honestly more than good enough.

You have the right attitude. I have worked with delusional individuals who one day "soon" expect to mypy check their entire several hundred thousand line legacy code base. This is supposed to be a boon to developer productivity. I hope it outweighs what was lost getting to this point.

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

#530

Post by icedchai »

nine_zeros wrote: post #525
cjalmeida wrote: post #482

Earlier quoted context omitted.

You know you can use type aliases, right?

So now you are going to create complex types and then create aliases for them? What are we even developing at this point?

Some people love this. They spend more time screwing around with types and related tooling than writing actual working code.
Post reply on HN