[Python-Dev] When should pathlib stop being provisional?
steve at pearwood.info
Wed Apr 6 10:39:12 EDT 2016
On Wed, Apr 06, 2016 at 11:30:32AM +0200, Petr Viktorin wrote:
> Python was in a similar situation with the .next method on iterators,
> which changed to __next__ in Python 3. PEP 3114 (which explains this
> change) says:
> > Code that nowhere contains an explicit call to a next method can
> > nonetheless be silently affected by the presence of such
> > a method. Therefore, this PEP proposes that iterators should have
> > a __next__ method instead of a next method (with no change in
> > semantics).
> How well does that apply to path/__path__?
I think it's potentially the same. Possibly there are fewer existing
uses of "obj.path" out there which conflict with this use, but there's
at least one in the std lib: sys.path.
> That PEP also introduced the next() builtin. This suggests that a
> protocol with __path__/__fspath__ would need a corresponding
> path()/fspath() builtin.
Not necessarily. Take a look at (say) dir(object()) and you'll see a few
dunders that don't correspond to built-ins:
__reduce__ and __reduce_ex__ are used by pickle;
__sizeof__ is used by sys.getsizeof;
__subclasshook__ is used by the ABC system;
Another example is __trunc__ used by math.trunc().
So any such fspath function should stand on its own as a useful
feature, not just because there's a dunder method __fspath__.
More information about the Python-Dev