[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 <[EMAIL PROTECTED]> European Bioinformatics Institute _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
