[Python-ideas] Type hinting for path-related functions
Koos Zevenhoven
k7hoven at gmail.com
Sun May 15 06:55:49 EDT 2016
A copy-paste error of mine corrected below, sorry.
On Sun, May 15, 2016 at 1:51 PM, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> On Sat, May 14, 2016 at 2:41 AM, Brett Cannon <brett at python.org> wrote:
>>
>> On Fri, 13 May 2016 at 16:14 Koos Zevenhoven <k7hoven at gmail.com> wrote:
>>>
>>> On Sat, May 14, 2016 at 2:05 AM, Brett Cannon <brett at python.org> wrote:
>>> >
>>> > On Fri, 13 May 2016 at 15:09 Koos Zevenhoven <k7hoven at 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] -> bytes:
> ...
corrected to "-> bytes"
> and
>
> @overload
> def fspath(p: Union[str, StrPath]) -> str:
> ...
> @overload
> def fspath(p: Union[bytes, BytesPath] -> bytes:
> ...
corrected to "-> bytes"
> - Koos
>
> P.S. The situation with DirEntry requires more considerations, because
> it can have either underlying type.
More information about the Python-ideas
mailing list