[Python-Dev] When should pathlib stop being provisional? (original) (raw)

Nathaniel Smith njs at pobox.com
Wed Apr 6 10:50:23 EDT 2016

On Apr 6, 2016 07:44, "Steven D'Aprano" <steve at pearwood.info> wrote:

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 reduceex 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.

An even more precise analogy is provided by index, whose semantics are to provide safe casting to integer (the name is a historical accident), as opposed to int's tendency to cast things to integer willy-nilly, including things that really shouldn't be silently accepted as integers. Basically index is to int as (fs)path would be to str.

There's an operator.index but no builtins.index.

-n -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160406/f8033759/attachment-0001.html>

More information about the Python-Dev mailing list