On Wed, May 24, 2017 at 3:41 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> On Wed, May 24, 2017 at 12:18:16AM +0300, Serhiy Storchaka wrote:
>> 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
>
These are not reasonable use cases because they should not subclass
str or bytes. That would be confusing.
> 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
>
You can monkeypatch the stdlib:
from os import fspath as real_fspath
mystr = "23"
def fspath(path):
if path is mystr:
print("fspath was called on mystr")
return real_fspath(path)
os.fspath = fspath
try_something_with(mystr)
Having __fspath__ on str and bytes by default would destroy the
ability to distinguish between PathLike and non-PathLike, because all
strings would appear to be PathLike. (Not to mention the important
compatibility issues between different Python versions and different
ways of dealing with pre-PEP519 path objects.)
—Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
