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