[Python-Dev] The path module PEP

[Paul Moore]

On 1/26/06, Thomas Wouters <thomas at xs4all.net> wrote:
> On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJörn Lindqvist wrote:
>
> > Inheritance from string (Jason)
>
> > This issue has been brought up before when people were discussing the
> > path module. I think the consensus is that, while the inheritance
> > isn't pure, practicality beats purity. It would require to big changes
> > to Python and would break to much existing code to not extend string.

I don't think there is consensus at all. I've seen plenty of
arguments, either directly against inheritance from string, or against
features which exist *because* of the inheritance (e.g., we can't use
join() because it's a string method).

> This is my only problem with the PEP. It's all very nice that subclassing
> from string makes it easier not to break things, but subclassing implies a
> certain relationship. That relationship doesn't exist, in this case. Having
> the string subclass behave differently than strings (consider the __iter__
> and join methods) is a bad idea. I can dish up a half dozen contrived
> problem cases, but the main reason I don't like it is that it feels wrong.

Agreed. Path objects don't feel like strings to me, either. It's
certainly *arguable* that "paths are strings" in some ideal sense, but
in a very practical sense they are not. Operations like split, join,
justification, trimming, all of which are part of the Python string
type (and hence constitute part of what it means to "be a string" in
Python) do not have any sensible meaning on paths.

The only justification for making Path a string subtype seems to me to
avoid a few conversions - open(path) rather than open(str(path)), for
example. I'd rather have to explicitly convert, to be honest. (But I'd
happily accept changes to open etc to take path objects directly).

> If the reason to subclass string is that it's too hard to make an object
> 'string-like' at a low enough level for the C API, I suggest fixing that,
> instead. If that means Path has to wait until Python 2.6, then that's too
> bad. The inability to feed C functions/types open() non-string objects has
> troubled me before, and though I haven't invested a lot of time in it, I
> don't quite understand why it isn't possible. Fixing it in a
> backward-compatible manner may require a new __hook__, although I think
> using __str__ or __unicode__ shouldn't be too problematic.
>
> Even if fixing the "%es"/"%et" etc formats to the arg-parsing methods is
> infeasible, I would prefer a new format code for 'string-alike as C string'
> over the unpythonic inappropriate subclassing. Although, even if the
> subclassing was completely appropriate, I would much rather improve builtin
> support for ducktyping than showcase subclassing ;)

Adaptation (PEP 246) would let paths be *adaptable* to strings,
without *being* strings... :-)

Paul.