Hacker News Reader

Comment by sota_pop | Hacker News Reader

Python types - all the onus of static types, with none of the performance!

I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props.

Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type in variable-like syntax at the top: mytype = int|str|list|etc.

View on HN

There is an important (I would say primary) benefits of types that isn't performance: it's making a program structure [you | your IDE | LLMs] can reason about.

Agreed, it definitely improves my experience when the compiler “knows” the variable types.

The most annoying part is that the type checking exists outside the regular runtime. I constantly run into situation where the type checker is happy, but the thing explodes at runtime or the type checker keeps complaining about working code. And different type checkers will even complain about different things regularly too. It's a whole lot of work making every part of the system happy and the result still feels extremely brittle.

They ARE only “hints” afterall.

> with none of the performance!

If you care about micro-optimizations, the first one that overwhelms everything else is to not use Python.

Anyway, if your types are onerous, you are using them wrong. Even more in a progressive type system where you always have the option of not using them or putting an "Any" there.

While most responders seem to have latched on to the pedantics of my “oop” comment - this is what my comment was intended to imply: why force the verbosity of static types on Python when statically typed (sic compiled) languages typically have much better runtime performance? the real answer i suspect is for quality of life/readability of code, but they are just “hints” afterall.

Yes, as you suspect, Python developers don't use types for performance.

You are consistently showing you ignore how to use types and what they can do. Nobody is required to know about everything, but keep in mind that this is a lack from your part to understand it, not from the language.

Ruby doesn't have multiple constructors and literally everything in Ruby is an object so it's partically impossible to avoid "doing OOP". I don't see how being "truely OOP" has anything to do with the language supporting method overloads.

One shouldn't be implementing anything "trully OOP" to begin with...

Quotes speak louder than words… However it’s hard to say “what one should or shouldn’t” be implementing in general terms.

I find the type hints harder and slower than java/C/...

try typing a decorator, or anything using file IO

I find it extremely difficult, if not impossible, and I did type theory

(the type checkers being really, really stupid doesn't help either)

So don’t? Just annotate the stuff that’s not annoying. I agree, IO is annoying to type. Decorators are fine, it’s just a function that returns a function. It’s still a win, however much you decide to annotate.

What does "multiple constructors" buy you that you can't get from multiple static methods that return an object of the enclosing class's type.

Maybe I'm missing out on something cool...

Perhaps just a fuzzy feeling. I suppose I haven’t tried using static methods for that purpose. Will give it a shot!

Python types - all the onus of static types, with none of the power of calculus of constructions. /s

Reply on news.ycombinator.com