It seems like the author is looking for the ability to specify types as `typeof <function>:arguments` and `typeof <function>:return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.

The thing that the author says they would prefer is already in Python, it's called NewType (https://docs.python.org/3/library/typing.html#typing.NewType)

They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them."

`MyType = NewType('MyType', Any)`

is how you do this.

At the end, they suggest a workflow: "I think my ideal type hint situation would be if I could create distinct but otherwise unconstrained types for things like function arguments and function returns, have mypy or other typing tools complain when I mixed them, and then later go back to fill in the concrete implementation details of each type hint"

That's just doing the above, but then changing the `NewType('MyType', Any)` to something like `NewType('MyType', list[dict[str, int]])` later when you want to fill in the concrete implementation.

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/

We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

> In writing this it occurs to me that I do often know that I have distinct types (for example, for what functions return) and I shouldn't mix them, but I don't want to specify their concrete shape as dicts, tuples, or whatever. [...] Type aliases are explicitly equivalent to their underlying thing, so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them.

It sounds to me like you're describing the NewType pattern which is just slightly farther down the page you linked in the article.

https://docs.python.org/3/library/typing.html#newtype

Type hints are nice, until you have to interact with a library that isn't type-hinted, and then it very quickly becomes a mess.

I don't know how other IDEs behave, but VScode + the Python extensions try to infer the missing hints and you end up with beauties such as `str | None | Any | Unknown`, which of course are completely meaningless.

Even worse, the IDE marks as an error some code that is perfectly correct, because it somehow doesn't match those nonsensical hints. And so it gives you the worst of both worlds: a lot of false positives that you quickly learn to ignore, dooming the few actual type errors to irrelevance, because you'll ignore them anyways until they blow up at runtime, just as it'd happen without typehints.

The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable.

I'm missing a lot simple functions with explicit argument names and docstrings with arguments types and descriptions clearly but discreetly documented.

It was one big strength of Python to have so simple and clean code without too much boilerplate.

Also, I have the feeling that static typing extremist are trying to push the idea that type hinting allows to ensure to not mix types as it would be bad. But from my point of view the polymorphic and typing mixing aspect is a strong force of Python.

Like having dictionaries that are able to hold whatever you want is so incredible when you compare to trying to do the equivalent in Java for example.

One part where I find type hint to be wonderful still is for things like pydantic and dataclasses!

My objection to strong types in python is philosophical. Python mimics natural language, and natural language rejects strong types for context resolved ambiguity.

In the way we resolve these issues in natural language, we can resolve bugs in python, that is, “do you mean integer ’3’ or string’3’” instead of insisting we define everything always forever.

To me, people who use type hinting are just letting me know they have written code that doesn’t check in line.

The problem (in my opinion) is that Python gives you the tools (and perhaps even encourages you) to write code that would benefit from typing.

It's perfectly feasible to write maintainable, well-designed code in a dynamic language. I've worked with some extremely robust and ergonomic Clojure codebases before, for example. However, in Clojure, the language pushes you into its own "pit of success".

Personally, I never feel that with Python.

Type hinting in python is a bit of a sticky plaster.

We have pyre enforcement at work, the problem is, that it has been gradually turned on over time, so some stuff is pyre compliant (or just strategically ignored) and some stuff isnt, so when you open some old code to do something, you have a million errors to deal with.

That would be fine if types were enforceable. in runtime type hinting does shit all.

I would dearly love a "strict" mode where duck typing is turned off and variable are statically typed. However I suspect that will never happen, even though it'd speed up a load of stuff if done correctly (type inference happens a lot)

I suspect to use type hints properly, I'd need to think a bit more C-like and create dataclasses as types to make things more readable, rather than using Dict[str,int] or what ever.

This is what we ended up using with mypy so we could add type checks to our CI without having to fix every single typing error:

https://github.com/orsinium-labs/mypy-baseline

I typehint the stuff that is easy. My observations about typehinting in Python track the 80:20 rule or even a 90:10 rule. You get about 80% benefit for typhinting the easy 20%.

> yet another Python thing I'd have to try to keep in my mind despite it being months since I used them last.

Typing hints are also a moving target: they have changed, sometimes significantly, on every minor Python release since they came to be.

The `Optional` type came and went (being replaced by the new Union syntax.) Type classes are usually born in the `typing` module, then some of them get moved to `collections`, `abc`, or `collections.abc`. Some types have even been moved several times. `TypeAlias` came and went (replaced by `type`). `List` became `list`. `Tuple` became `tuple`. Forward declarations require a workaround by using string literals. But in Python 3.14, they no longer do, and the workaround will become deprecated.

I'm an evangelist for static type checking, and I never write a Python function signature without complete typing annotations. I also think that typing annotations in Python are evolving in a good way. However, for long-lived Python scripts, I highly recommend that developers are aware of, and factor in, the effort necessary to keep up with the evolution of static typing across Python versions. That effort spent on migrating is going to come on top of the mental load that typing hints already add to your plate.

> PPS: I think my ideal type hint situation would be if I could create distinct but otherwise unconstrained types for things like function arguments and function returns, have mypy or other typing tools complain when I mixed them

Cleaner/safer function args and return types is a common motivation for dataclass. has benefits over many/complex args besides typing too.

this is not a just a python problem but a problem in many dynamic languages.

switching to the typed variants whether typecript, python type-hints, mypy etc will force you to do the dance to make the compiler happy instead of working on code.

which is why for me - JSDoc is really good - it uses types for documentation and ends there.

Sometimes I feel like we need an analog to javascript/typescript. Ptypethon if you will.

It’s kind of cool that type hints can be reflected on to do things (see Pydantic). Other than that I find it pretty cumbersome to use in practice, coming from TypeScript. Semi-relatedly I also dislike Python’s different ways to access objects/dicts, it feels arbitrary and cumbersome.

Program the way you like it and it should be fun.

If you are at work doing professional programming then typing helps avoid bugs and makes programming more of a reliable and robust process.

But doing your own thing, doing little utilities, banging out quick stuff, do exactly what makes you happy.

Programming should be fun not a chore and if types make it a chore for you then drop them.

Is that a double negative in your title ? Or is it an inside joke I didn't get ?

That's why they are not unspecified to be optional.