[Python-ideas] Better stdlib support for Path objects

[Donald Stufft]

> On Oct 7, 2014, at 2:57 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> 
> On Mon, Oct 6, 2014 at 7:58 PM, Antoine Pitrou <solipsis at pitrou.net <mailto:solipsis at pitrou.net>> wrote:
> Not inheriting from built-in classes such as str, list or tuple
> was one of the design points of pathlib. It will not change in the
> future ;-)
> 
> PEP 428 outlines this, but you can probably find a more detailed
> discussion in the python-ideas archive.
> 
> See also rejected PEP 355: "Subclassing from str is a particularly bad idea; many string
> operations make no sense when applied to a path."
> 
> http://legacy.python.org/dev/peps/pep-0355/ <http://legacy.python.org/dev/peps/pep-0355/>
> 
> (I would add that many str operations make no sense - period, so propagating them into newer designs would be a mistake.)

Many str operations make no sense when applied to lots of different types of strings, even moreso many bytes methods make no sense when applied to any kind of bytes except a very narrow subset. I’m pretty sure that “does every single method make sense in every scenario” it not a useful distinction to make. However the sheer weight of APIs out there that expect str, and only str means that either pathlib isn’t very useful without wrapping every call in a str() or using some attribute/method on it to convert to str.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141007/aa38c074/attachment.html>