Home Original page

[Python-Dev] When should pathlib stop being provisional?

Steven D'Aprano 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__.


-- 
Steve
More information about the Python-Dev mailing list