[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@ebi.ac.uk> European Bioinformatics Institute