On Sat, May 14, 2016 at 1:08 AM, Koos Zevenhoven firstname.lastname@example.org wrote:
On Fri, May 13, 2016 at 11:50 PM, Ethan Furman email@example.com wrote:
On 05/13/2016 01:30 PM, Koos Zevenhoven wrote:
It turns out it has been almost a month since this, and the PEP draft is already looking good. It seems we might now be ready to discuss it. Should we add the generic type FSPath[str]?
Guido's post on one of the other threads:
There's no need for typing.PathLike.
So I'm gonna say no. ;)
Oh, it looks like a read those two emails in the wrong order ;).
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.
But maybe making it a generic type would be the way to make the type checker to understand it?
Of course if subscripting the ABC is not desired, there could be three ABCs, something like os.StrPath (for str-based path types) and os.BytesPath (for bytes-based path types) and os.StrBytesPath (for str/bytes like DirEntry, unless such classes are split in two). But I suppose there is nothing that would help combining this with a TypeVar-like thing.
Then again, when working in pure python with a pure python fspath and with the __fspath__ method properly annotated in the path class, the type checker should probably be able to infer the types. Maybe Guido was referring to this.
Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/