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.
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. 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 ;) But perhaps I've missed that single, all-convincing argument that it has use subclassing... In that case, could it be added to the PEP? :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!