(original) (raw)

On Apr 6, 2016 07:44, "Steven D'Aprano" <steve@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 \_\_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\_\_.

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