Introduce typing.SupportsFsPath
Hello,
Since __fspath__ was introduced in PEP 519 it is possible to create object classes that are representing file system paths. But there is no corresponding type object in the "typing" module. Thus I cannot specify functions, that accept any kind of object which supports the __fspath__ protocol.
Please note that "Path" is not a replacement for "SupportsFsPath", since the concept of PEP 519 is, that I could implement new objects (without dependency to "Path") that are implementing the __fspath__ protocol.
robert
In typeshed there is os.PathLike which is close. You should be able to use Union[str, os.PathLike[str]] for what you want (or define an alias).
We generally don't want to add more things to typing that aren't closely related to the type system. (Adding the io and re classes was already less than ideal, and we don't want to do more of those.)
On Mon, Oct 8, 2018 at 3:10 PM robert.hoelzl@posteo.de wrote:
Hello,
Since __fspath__ was introduced in PEP 519 it is possible to create object classes that are representing file system paths. But there is no corresponding type object in the "typing" module. Thus I cannot specify functions, that accept any kind of object which supports the __fspath__ protocol.
Please note that "Path" is not a replacement for "SupportsFsPath", since the concept of PEP 519 is, that I could implement new objects (without dependency to "Path") that are implementing the __fspath__ protocol.
robert _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, 9 Oct 2018 at 03:13, Guido van Rossum guido@python.org wrote:
In typeshed there is os.PathLike which is close. You should be able to use Union[str, os.PathLike[str]] for what you want (or define an alias).
We generally don't want to add more things to typing that aren't closely related to the type system. (Adding the io and re classes was already less than ideal, and we don't want to do more of those.)
The problem however is that `PathLike` is not a protocol in typeshed. This should be updated when protocols will be official. Until that, you can just easily define your own protocol:
from typing import AnyStr from typing_extensions import Protocol
class PathLike(Protocol[AnyStr]): def __fspath__(self) -> AnyStr: ...
-- Ivan
On Tue, Oct 9, 2018 at 3:16 AM Ivan Levkivskyi levkivskyi@gmail.com wrote:
class PathLike(Protocol[AnyStr]):
I had been working on this same problem intermittently for several months, so thanks, but...
error: Invariant type variable 'AnyStr' used in protocol where covariant one is expected
is called out on the class by mypy 0.630 (Python 3.6.6). Do I just need to wait for 0.640? Or should I define a new TypeVar for AnyStr_co and use that?
On Tue, 9 Oct 2018 at 15:17, Eric Fahlgren ericfahlgren@gmail.com wrote:
On Tue, Oct 9, 2018 at 3:16 AM Ivan Levkivskyi levkivskyi@gmail.com wrote:
class PathLike(Protocol[AnyStr]):
I had been working on this same problem intermittently for several months, so thanks, but...
error: Invariant type variable 'AnyStr' used in protocol wherecovariant one is expected
is called out on the class by mypy 0.630 (Python 3.6.6). Do I just need to wait for 0.640? Or should I define a new TypeVar for AnyStr_co and use that?
Hm, it looks like mypy overreacts here. I think it should be safe to use a constrained type variable if there are no constraints that are subtypes of other constraints (which is the case for AnyStr on Python 3, where bytes is not a subtype of str). Could you please open an issue about this on mypy tracker? In the meantime, you can just silence the error with a `# type: ignore`.
-- Ivan
Done https://github.com/python/mypy/issues/5775
On Thu, Oct 11, 2018 at 1:47 PM Ivan Levkivskyi levkivskyi@gmail.com wrote:
On Tue, 9 Oct 2018 at 15:17, Eric Fahlgren ericfahlgren@gmail.com wrote:
On Tue, Oct 9, 2018 at 3:16 AM Ivan Levkivskyi levkivskyi@gmail.com wrote:
class PathLike(Protocol[AnyStr]):
I had been working on this same problem intermittently for several months, so thanks, but...
error: Invariant type variable 'AnyStr' used in protocol wherecovariant one is expected
is called out on the class by mypy 0.630 (Python 3.6.6). Do I just need to wait for 0.640? Or should I define a new TypeVar for AnyStr_co and use that?
Hm, it looks like mypy overreacts here. I think it should be safe to use a constrained type variable if there are no constraints that are subtypes of other constraints (which is the case for AnyStr on Python 3, where bytes is not a subtype of str). Could you please open an issue about this on mypy tracker? In the meantime, you can just silence the error with a `# type: ignore`.
-- Ivan
participants (4)
-
Eric Fahlgren -
Guido van Rossum -
Ivan Levkivskyi -
robert.hoelzl＠posteo.de