[Python-Dev] The path module PEP

[Michael Hoffman]

[Thomas Wouters]
>>> [Subclassing string] 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.

[Michael Hoffman]
>> This is the soul of arguing for purity's sake when practicality would
>> dictate something else.

[Thomas Wouters]
> If we're going to argue that point, I don't believe this is the practicality
> that the 'zen of python' talks about. Practicality is the argument for
> 'print', and for requiring the ':' before suites, and for some of the
> special cases in the Python syntax and module behaviour. It isn't about the
> implementation. The argument to subclass string is, as far as I can tell,
> only the ease of implementation and the ease of transition. Nothing in the
> old thread convinced me otherwise, either. I've never seen Guido go for an
> implementation-practical solution just because he couldn't be arsed to do
> the work to get a conceptually-practical solution. And subclassing string
> isn't conceptually-practical at all.

I don't understand what "conceptually-practical" is or how it differs
from "conceptually pure" which is what it seems that you're looking
for. It's not hard to give Path a has-a relationship to basestring
instead of an is-a relationship, so it really doesn't save much in
terms of implementation.

>> If you remove the basestring superclass, then you remove the ability
>> to use path objects as a drop-in replacement for any path string right
>> now.  You will either have to use str(pathobj) or carefully check that
>> the function/framework you are passing the path to does not use
>> isinstance() or any of the string methods that are now gone.
>
> More to the point, you will have to carefully check whether the
> function/framework will use the Path object in a way the Path object can
> handle. There's already discussion about whether certain methods should be
> 'disabled', in Path objects, or whether they should be doing something
> conceptually different.

Yes, and I think all of this discussion is focused on conceptual
purity and misses one of the big wins of the Path module for current
users--it can be trivially used anywhere where a str is expected
today. If you're going to start deciding that certain str methods
should be disabled for some reason, then it shouldn't be a str
subclass, because it will no longer behave like string-plus.

In previous discussions, string methods were identified that one
programmer thought would not be useful on a path, but others
disagreed. Disabling methods serves no useful purpose, except to
shorten dir().

I've been using path.py for some time, and I can tell you that it
would be a lot less useful if it no longer behaved like string-plus.
-- 
Michael Hoffman <hoffman at ebi.ac.uk>
European Bioinformatics Institute