On Sat, May 14, 2016 at 2:41 AM, Brett Cannon <brett@python.org> wrote:
On Fri, 13 May 2016 at 16:14 Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Sat, May 14, 2016 at 2:05 AM, Brett Cannon <brett@python.org> wrote:
On Fri, 13 May 2016 at 15:09 Koos Zevenhoven <k7hoven@gmail.com> wrote:
Anyway, I was going to suggest making the abstract base class subscriptable too like this: PathABC[str] is a str-based path ABC, and PathABC[bytes] a bytes-based one ;). I don't know if that should be called a generic type or not, though.
The PEP already addresses this and says "no".
I obviously know the PEP very well, and it doesn't. But I'm probably just doing a bad job explaining what I mean right now, and should probably go to bed. Sorry.
Ah, I now see what you're proposing: somehow making the ABC a generic like the generics types in the typing module are (which would be a new feature for ABCs and why I didn't realize what you were initially asking for; sorry about that). The answer is still "no". :)
I'm not sure that this is strictly a new feature, although I suppose there is no example of such an ABC at the moment in the stdlib. But I suppose there is a reason why, for instance, typing.Sequence and collections.abc.Sequence are not merged together. Maybe that is to limit the complexity of the already complex type stuff at this point. The question of whether the ABC could be subscripted to determine the underlying type can be viewed as separate from whether it inherits from Generic[...] or not. But IIUC, inheriting from Generic[...] is the thing that Mypy understands.
The generics support from the typing module is specific to that module and not applicable to ABCs themselves.
Specific to that module? Maybe you mean the convention of having the stdlib generics in typing.py.
Think of ABCs as helping guarantee that you implement specific methods and attributes.
Yes, that's pretty much what I do ;-). And as I already suggested, one could also avoid the subscripting part by defining separate ABCs, os.StrPath, os.BytesPath. This still wouldn't allow parametrizing with a TypeVar, but at least one could write [for os(.path) functions] @overload def dirname(p: Union[str, StrPath]) -> str: ... @overload def dirname(p: Union[bytes, BytesPath] -> str: ... and @overload def fspath(p: Union[str, StrPath]) -> str: ... @overload def fspath(p: Union[bytes, BytesPath] -> str: ... - Koos P.S. The situation with DirEntry requires more considerations, because it can have either underlying type.