We define the same TypeVar (with the same name) in builtins.pyi and os/__init__.pyi — is it worth adding it to _typeshed, do you think?

It's simple enough that I don't mind redefining it, but I don't feel strongly.

We can leave it for now

This is annoying, but it doesn't look like there's any other way of doing this.

Sebastian opened a conversation a while ago about allowing arguments without defaults to follow arguments with defaults, which would make this easier, but it didn't go anywhere.

There was some pushback, because that's mostly useful for typing and considered bad API design otherwise, but honestly more from typing-critical developers, if I remember correctly.

Plus ça change, plus c'est la même chose

An alternative could be to add a special marker like typing.NO_DEFAULT, which we'd use as the default. That would look like this:

        @overload
        def __init__(
            self: FileInput[bytes],
            files: StrOrBytesPath | Iterable[StrOrBytesPath] | None = ...,
            inplace: bool = ...,
            backup: str = ...,
            bufsize: int = ...,
            mode: Literal["rb"] = NO_DEFAULT,
            openhook: Callable[[StrOrBytesPath, str], _HasReadlineAndFileno[bytes]] | None = ...,
        ) -> None: ...

And the semantics would be that type checkers don't pick the overload if no value is given for mode, but it's still the 6th positional argument.

An alternative could be to add a special marker like typing.NO_DEFAULT, which we'd use as the default.

Oh, I like that quite a lot, actually. It would mean we wouldn't have to change Python's grammar at all. It does also feel like the kind of thing that would disproportionately benefit typeshed, though.

There was also a recent mypy issue where end-users were complaining about this, so it might be more broadly useful. If @srittau likes it too I can send it to typing-sig.

It should be possible to write a script that automatically applies NO_DEFAULT in typeshed wherever possible. I would be interested to see the results,

This was the thread. Looking back at it, the push back wasn't too bad. Maybe it would be worth trying again with a complete PEP?

I'm not particularly fond of typing.NO_DEFAULT, but would prefer it over the status quo.

I think I actually prefer typing.NO_DEFAULT. The status quo is definitely annoying for type annotations, but I think syntax changes should have to meet a pretty high bar, and I'm not sure this meets that bar ://

typing.NO_DEDAULT feels like it would be much simpler to implement with minimal changes to the language itself (and it would also be much easier to backport).