I understand why users of typing are wary of such things, but at the same time I know very good developers who don’t use typing.
I think it largely depends on a situation. E.g. for small expert teams typing would potentially just slow things down.
And CPython standard library itself is not using typing… So although I understand POV of those who care about such things, but to me it seems that although keeping typing in mind is important, the weight to decisions as such should be much smaller.
And also, as opposed to new things being blocked by “hard to write typing”, such things could instead serve as pointers to where typing could / should be improved.
Yes, that makes sense. Would need to check what typecheckers do for partial.
But I would rather see typing extensions for “conditionals”.
Also, I have just realised, there is one more nuance in proposed variation:
f = pipe()
# is the same as:
f = lambda x: x
To me this seems like a fun puzzle for typing experts.
P = ParamSpec('P')
I = TypeVarIter('I')
class pipe[**P]:
def __new__(cls, *funcs: Tuple[Callable[P, T[0]], Callable[T[I], T[I+1], 0, None]] | None[0]) -> Self: ...
def __call__(self, *args: P.args if T.min == 0 else T, **kwargs: None if None[0] else P.kwargs) -> T1 if None[0] else T[0]
I do as well. Being a good Python developer and using typing are fully orthogonal.
I am very firmly not saying that everyone should or must use a type checker. What I’m saying is that anyone thinking about new features for the language and stdlib ought to consider what they are asking of type checkers and typing design.
You don’t have to agree with that, but I want to be very clear that this opinion is about language features, not language users.
I agree. It’s no different than asking how does a new feature interact with any other existing language feature. If a new feature didn’t work well with multiple inheritance, that would be a problem. Replace “multiple inheritance” with typing.
Typing is a first class language feature, just like multiple inheritance. You don’t have to use multiple inheritance if you prefer not to either.
Multiple inheritance doesn’t penetrate every aspect of the language, while typing does.
Multiple inheritance is a part with which all other parts need to play nicely.
While typing is an extra layer on the whole.
There is a POV from which these are the same.
However in practice I think implications are different. Failures in effective expansion of something which is an “extra layer on the whole” might have much higher impact on progress.
I am not sure what exact differences does it currently make, but I think that there should be a pronounced emphasis developing typing to such a degree that it doesn’t obstruct the progress.
And I believe that exactly that might be happening, but as I am not exposed to conversations on high level strategy, I just don’t know.
I suppose this might be a sensible goal for typing.
I am just saying, that if this was violating “multiple inheritance” this would be a definite no-go.
While given this is typing, very valid POV is “ok, we need to put more emphasis on typing to accommodate more of the language.”
And yes, this is standard library extension proposal, but it has been shown that people are writing exactly same thing in their own libraries and typing can not support “perfectly valid language constructs”.
So I am happy to put this on hold until the right time, but I don’t think typing should be decisive factor for the fate of this. But rather this could serve as a pointer to where typing needs improving.
