On Wed, May 24, 2017 at 12:18:16AM +0300, Serhiy Storchaka wrote:
> 23.05.17 20:04, Brett Cannon пише:
> >What exactly is the performance issue you are having that is leading to
> >this proposal?
>
> It seems to me that the purpose of this proposition is not performance,
> but the possibility to use __fspath__ in str or bytes subclasses.
> Currently defining __fspath__ in str or bytes subclasses doesn't have
> any effect.
That's how I interpreted the proposal, with any performance issue being
secondary. (I don't expect that converting path-like objects to strings
would be the bottleneck in any application doing actual disk IO.)
> I don't know a reasonable use case for this feature. The __fspath__
> method of str or bytes subclasses returning something not equivalent to
> self looks confusing to me.
I can imagine at least two:
- emulating something like DOS 8.3 versus long file names;
- case normalisation
but what would make this really useful is for debugging. For instance, I
have used something like this to debug problems with int() being called
wrongly:
py> class MyInt(int):
... def __int__(self):
... print("__int__ called")
... return super().__int__()
...
py> x = MyInt(23)
py> int(x)
__int__ called
23
It would be annoying and inconsistent if int(x) avoided calling __int__
on int subclasses. But that's exactly what happens with fspath and str.
I see that as a bug, not a feature: I find it hard to believe that we
would design an interface for string-like objects (paths) and then
intentionally prohibit it from applying to strings.
And if we did, surely its a misfeature. Why *shouldn't* subclasses of
str get the same opportunity to customize the result of __fspath__ as
they get to customize their __repr__ and __str__?
py> class MyStr(str):
... def __repr__(self):
... return 'repr'
... def __str__(self):
... return 'str'
...
py> s = MyStr('abcdef')
py> repr(s)
'repr'
py> str(s)
'str'
I don't think that backwards compatibility is an issue here. Nobody will
have had reason to write str subclasses with __fspath__ methods, so
changing the behaviour to no longer ignore them shouldn't break any
code. But of course, we should treat this as a new feature, and only
change the behaviour in 3.7.
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
