On Thu, 10 Feb 2022 at 21:45, Brett Cannon <br...@python.org> wrote: > > > On Wed, Feb 9, 2022 at 11:59 AM Barney Gale <barney.g...@gmail.com> wrote: > >> Penny for your thoughts on those questions, Brett? Protocols are new to >> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a >> read now. >> > > Protocols would let folks rely on a common Path object API w/o having to > require the object come from pathlib itself or explicitly subclass > something (which I admit would be rare, but there's no reason to > artificially constrain this either). Now maybe this is too broad of an API > for people to care, but since protocols are also ABCs it doesn't inherently > make things worse, either. So I would say subclassing Protocol makes sense > while still using abc.abstractmethod for methods people must implement. > >
Thanks Brett. My only concern there is that the protocol would be /extensive/, encompassing all PurePath + Path methods. It's rather impractical to write a Path-compatible class without subclassing something from pathlib - and that impracticality is one motivation for this work! PEP 544 seems to make this point: > Protocol classes should generally not have many method implementations, as they describe an interface, not an implementation. Most classes have many method implementations, making them bad protocol classes. https://www.python.org/dev/peps/pep-0544/#make-every-class-a-protocol-by-default For now I've made _AbstractPath inherit abc.ABC, but I'm open to consider it further! Barney On Thu, 10 Feb 2022 at 21:45, Brett Cannon <br...@python.org> wrote: > > > On Wed, Feb 9, 2022 at 11:59 AM Barney Gale <barney.g...@gmail.com> wrote: > >> Penny for your thoughts on those questions, Brett? Protocols are new to >> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a >> read now. >> > > Protocols would let folks rely on a common Path object API w/o having to > require the object come from pathlib itself or explicitly subclass > something (which I admit would be rare, but there's no reason to > artificially constrain this either). Now maybe this is too broad of an API > for people to care, but since protocols are also ABCs it doesn't inherently > make things worse, either. So I would say subclassing Protocol makes sense > while still using abc.abstractmethod for methods people must implement. > > >> >> I reckon only stat(), open() and iterdir() would be essential for users >> to implement. >> > > Seems like a reasonable set to have to implement. > > -Brett > > >> >> On Wed, 9 Feb 2022 at 19:02, Brett Cannon <br...@python.org> wrote: >> >>> One thing to discuss (and which has been brought up on the PR), is >>> whether this should be an ABC to force people to explicitly raise >>> `NotImplementedError`? >>> >>> The next question is whether any of this should be a (very wide) >>> protocol instead of an ABC? >>> >>> On Wed, Feb 9, 2022 at 7:05 AM Barney Gale <barney.g...@gmail.com> >>> wrote: >>> >>>> Over the last couple of years I've been tidying up the pathlib >>>> internals, with a view towards adding an AbstractPath class to the >>>> hierarchy. Users would be able to subclass AbstractPath to implement other >>>> kinds of filesystems: s3, google cloud storage, pandas, ftp, git, zip and >>>> tar files, etc. By implementing some abstract methods (stat(), iterdir(), >>>> open(), etc) they'd benefit from a number of derived methods (is_dir(), >>>> glob(), read_text(), etc). There's already a healthy ecosystem of PyPI >>>> packages attempting this, but there's presently no officially-supported >>>> route. >>>> >>>> I've now submitted a PR that adds an initial underscore-prefixed >>>> implementation of this class: >>>> https://github.com/python/cpython/pull/31085. The implementation is >>>> simple: wherever Path calls functions in os, io, pwd, etc, AbstractPath >>>> instead raises NotImplementedError. The Path class becomes an >>>> implementation of AbstractPath. >>>> >>>> These methods directly raise NotImplementedError: cwd(), stat(), >>>> iterdir(), readlink(), resolve(), expanduser(), owner(), group(), open(), >>>> touch(), mkdir(), symlink_to(), hardlink_to(), rename(), replace(), >>>> chmod(), unlink(), rmdir() >>>> >>>> These methods call through to the above methods: absolute(), lstat(), >>>> exists(), is_dir(), is_file(), is_mount(), is_symlink(), is_block_device(), >>>> is_char_device(), is_fifo(), is_socket(), home(), samefile(), scandir(), >>>> glob(), rglob(), read_bytes(), read_text(), write_bytes(), write_text(), >>>> lchmod(), link_to() >>>> >>>> Some methods aren't applicable to some kinds of filesystems, e.g. zip >>>> files don't support symlinks, working directories or home directories. In >>>> these cases I think it's reasonable to raise NotImplementedError. Indeed, >>>> pathlib.Path methods already raise NotImplementedError when certain local >>>> filesystem features aren't available (readlink(), group(), etc). >>>> >>>> If any readers of this list have previously tried to extend pathlib to >>>> other domains, or are otherwise interested in pathlib development, please >>>> could you let me know what you think of the proposed API? >>>> >>>> Many thanks >>>> _______________________________________________ >>>> Python-Dev mailing list -- python-dev@python.org >>>> To unsubscribe send an email to python-dev-le...@python.org >>>> https://mail.python.org/mailman3/lists/python-dev.python.org/ >>>> Message archived at >>>> https://mail.python.org/archives/list/python-dev@python.org/message/JB7QGDNI2CNXFX7LQQ2X2WPOZ7DWVNQL/ >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IS54G4VU4HZUUVS5XLZXS3WYXK55CY44/ Code of Conduct: http://python.org/psf/codeofconduct/
