I would love to instead have one official upstream runtime type checker which can be enabled per function, class, or module via decorators. Basically, providing opt-in strong typing as a language feature.

Currently, I’m using the third-party Beartype decorators to provide this feature, but I would prefer something built-in and ideally something with more readable error messages for users when type errors occur, which might be easier to provide if it was built into Python.

(I use Pyright too, but I find the runtime type checking to be more robust since it understands also the types returned by highly dynamic untyped code.)

I don’t see that as a problem since you’re not going to run multiple type checkers over your code, much like most C++ codebases pick a compiler and stick to it.

> Go isn't a great example.

I picked Go as an example of a language that gets a lot of praise specifically for having strict compiler rules.

I've also tried Scala and found it clunky but I do suspect most of its problems came from the insane operator overloading and opaque build system rather than the type system. I understand it's gotten better since I looked 8 years ago but I've not had a reason to check it out again.

Having CI hard fail definitely helps. I won’t pretend I’d be so judicious without it.

If it works for you, great. I’ll also do that for the same reasons. What I really love, though, is I don’t need to be totally correct in my types all the time. If the code will run, it’ll run and, in plenty of simple cases, that’s good enough (even if mypy tells me I passed the wrong type).

> To me this suggests the tooling was insufficient.

Perhaps but I find that type systems usually introduce friction to getting things working that, for some types of projects, can be worthwhile and, for others, not worth the overhead.

This is both rude and ignorant. There is great value to exploration and experimentation, particularly for beginner programmers. Type systems do get in the way, and I say this as someone with 20+ years experience of modern (Scala, Haskell) type systems.

> Please, do not ever come next to my working place

Ok, I won't.

> we have enough problems already.

I agree.

  > The “problem” people try to   
  > solve with things like  
  > dependency injection isn’t  
  > even a problem in python.  
  > 99.99% of the time you can  
  > just import you dependencies  
  > everywhere they are needed.

Consider a function with `import datetime`, that gets the current time and does something with it. You want to make sure that this function still does the right thing in the extreme case of the current time being 23:59:59. How do you write this test without DI?

I find that good types help me model the problem and solution with clarity, and the procedures and functions take a back seat. After all, most procedures are just transformations of structured data, so putting the datastructure first makes good sense and keeps the code clean and lean. I used to believe in the “moving fast with no types” thing but in practice I find myself modeling the problem either way, it’s just clumsier without strong types.

Common Lisp was the first language I'm aware of with optional typing. In theory, what you're saying is true. In practice there's a lot of pressure to ship the working prototype, and retrofitting types on it later doesn't actually happen. The result was a reputation for being slow. (This was back when computers were slow enough that the overhead of being dynamic was pretty painful.)

“types are just arbitrary labels the language doesn’t even know about” is ok if you're aware of the limitations. I add typedefs and other jsdocs to javascript just because it makes it easier to work with in an IDE. it's nice to hover over a variable and see what it's "supposed" to be (if all went well this object should have a .id, might have a .name, etc), sometimes even declared as two types like "this variable is either an int or a boolean". I don't really want to bother learning typescript or trying to get coworkers to do so/put it in the pipeline so it's the best I can do and it certainly makes life a bit easier.

Unfortunately, when many people hear of static typing they think of C++ and Java, which understandably leads to these kinds of conclusions. If they ever bothered writing typed Python for a little bit, especially in new packages or projects where the surrounding code is also typed, they might realise how useful it is.

There's a world of difference between the experience you get with untyped Python and typed Python that you check with strict mypy or Pyright. After using typed Python for a while, I don't think I could go back to a completely untyped codebase.

> Have you ever tried static typing though? I suspect you don't know what you're missing. Static types make Python way easier to understand.

I'd probably call myself within the "dynamic typing crowd" and I've tried plenty of static typing. It mostly just slows down iterating on something, prevents issues that I/my projects don't really suffer from in the first place, and gets in the way more than it helps.

The statically typed languages I've tried are: C#, Crystal, Elm, Go, Haskell, Haxe, Java, Kotlin, Nim, Rust, TypeScript and probably more I'm forgetting about. Out of those, I've probably written most Rust code. I wouldn't say I despise static typing, but I'm not getting the same value from it that others seem to get.

I still come back to Clojure, ClojureScript or just straight up vanilla JavaScript, as they're much more effective at actually helping me solve the problem I have in my practical day-to-day.

You picked a poor example for `mean` because there's a very easy answer: collections.abc.Sequence – typing.Sequence in earlier versions – an object that supports __getitem__ and __len__. You can check the collections.abc documentation[1] for the available protocols; you might be surprised about how much they cover already. I often use Sequence/Iterable or Mapping as parameter types instead of concrete types like list or dict.

> I feel like a lot of people who want static typing everywhere want it as training wheels for other devs they don't trust to make the right judgement calls.

Now, I want it because it makes my life a lot easier. It finds many classes of errors before runtime and improves auto-completion in my editor. For most programs, it's not a lot of effort. The frustrating part is interfacing with untyped libraries while using strict type-checking, but thankfully, more and more libraries are adopting typing. The type system itself is fine: most things you want to express are doable, but it's not at the same level of complexity as Typescript. It's certainly a better type system than Go's for example.

[1] https://docs.python.org/3/library/collections.abc.html

> But having to do it everywhere? Ugh. I don't think people realise how powerful duck typing is for doing polymorphic code.

Duck typing is indeed powerful, but it does not need to be a runtime check.

> What am I going to do, define an ABC or typing.Protocol called `ListLike` or something?

Yes, how am I going to know what types I can pass to mean instead? I would go to the extreme of saying that a lot of python code should be type annotated (if annotated at all) with protocols instead of concrete or base classes.

Of course until type checking is properly integrated in the interpreter this is all kind of pointless.

if only there was some way for this structural documentation to also cause incorrect programs to be rejected

Just because a type system is optional doesn't mean it doesn't do anything, it just means that you can control how much checking you get, both in terms of the code that is typechecked and how strictly it is checked. Avoiding some type errors through type checking is much better than not having any type checking. Or put another way, optional seat belts are much better than not seat belts at all.

Most people using strong typesystems care less about safety of imported code and more about usability of their own codebase.

That misses the primary reasons many people use Python: the ecosystem and network effects. I would not use Python if it weren't the only language my colleagues know (many of them not computer scientists by training) and if it didn't have the best (or second/third best) libraries for almost everything.

What is ChatGPT written in?

Because it would be hilarious if ChatGPT was itself written in Python.

If you're using dynamic systems properly, it should be very empowering, and the lack of types is not really perceptible. If anything, it reduces the time code my moving things (having to consider types) out of my brain. I can just imagine what I want the code to do and type it, and most of the time it just kind of works out.

Mind you, I prefer a type system. I'd prefer to use Typescript over Javascript, etc. But I've also used a number of dynamic languages that let me work a lot faster when needed; Tcl, Ruby, and Python are examples of these.

I've also used some type systems that lift a heavier load, letting me pay more attention to the type definitions and know that it will "just work" at the end, because, mathematically, it works. Haskell falls into this category (though I rarely use it for anything other than fun).

I get it, you haven't use a dynamic system in a way that it works out for you. But that doesn't mean they're wrong... just that others have different experiences.

Yes I know the slotted attribute is not in a __dict__, which definitely helps memory usage. But my point is that if the parent structure is itself in a dict, that access will swamp the L1 cache miss in terms of latency. Even the interpretation overhead (and likely cache thrashing) will eliminate L1 cache speedups.

And yes __slots__ improve perf, but it’s about avoiding the __dict__ access, which hits really generic hashing code and then memory probing more than it is about L1 cache

Where __slots__ are most useful (and IIRC what they were designed for) is when you have a lot of tiny objects and memory usage can shrink significantly as a result. That could be the difference between having to spill to disk or keeping the workload in memory. E.g., Openpyxl does with a spreadsheet model, where there could be tons of cell references floating around

Good point. It’s more about choosing a good algorithm though.

A brute force O(N) in C++ may be fast enough, in a situation where you need to use O(logN) to get the equivalent speed in Python. Squeezing out a few extra percent from a O(N) in Python by using slots will not be enough.

Of course that doesn’t mean you shouldn’t leave performance on the table if the optimizations have noticeable effects.

I actually have a function for this! I use it all the time and it's super helpful.

    T = TypeVar("T")
    U = TypeVar("U")
    V = TypeVar("V")
    P = ParamSpec("P")

    def modelargs(model: Callable[P, U]):
        def _modelargs(func: Callable[[T], V]) -> Callable[P, V]:
            def __modelargs(*args: P.args, **kwargs: P.kwargs) -> V:
                return func(model(*args, **kwargs))  # type: ignore
            return __modelargs  # type: ignore
        return _modelargs

    class MyModel(BaseModel):
        foo: str
        bar: int = 4

    @modelargs(MyModel)
    def test_func(model: MyModel):
        print(model.foo, model.bar)
        return 4

    test_func(foo="Hello", bar=20)  # -> prints Hello 20

Huge proponent of Pydantic.

That said, there's also msgspec [1], which I've not used yet but plan to for my next project. It is supposedly quite a bit faster than Pydantic in de/serialization.

[1] https://jcristharif.com/msgspec/

I looked up the docs as to what frozen does:

> whether or not models are faux-immutable, i.e. whether __setattr__ is allowed (default: True)

Seems everything is “faux” in Python world when it comes to typing ;)

Which is why you use a type checker to ensure that it never happens in the codebase. If there is no line of code that ever does something like

    int_field: int = "string"

    self.int_field = "string"

There are some exceptions to this, like I said in the previous comment, but I think when getting started with typed Python, it's easier to assume that the types will be valid, because that's the case almost all of the time. Usually, overriding type assertions requires some kind of explicit cast or statement, and this is usually documented.

And here I thought the point of Internet forums was to prove who has the bigger uppey votey number!

Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.

https://news.ycombinator.com/newsguidelines.html