> > - Create a common base class of str and unicode, which should be an > > abstract class. This is the most OO solution, but I can't think of > > a good name; abstractstring is too long, AbstractString or String > > are uncommon naming conventions for built-in types, 'string' would > > almost work except that it's already the name of a very common > > module.[*] > > +1. This would be nice and the same could be done for sequences, file-like > objects and other common currently interface-defined object categories. > > About the naming: how about numberclass, stringclass, sequenceclass, > fileclass ?! > > Then you could write: > > if isinstance(obj, stringclass): ... > > which looks OK and is not too much typing. Hm, I don't know if "class" is the proper suffix to mean "abstract base class". I think I'll either call it "numberbase" or "abstractnumber". > The advantage of this approach is that it can be extended to other > types and classes as well (much like you can currently do with the > Python exceptions). Yup, that's why it's the most OO solution. :-) > With the new type logic in place, how hard would it be making > the existing built-in types subclasses of these base types ? That would be a prerequisite! > (also: is there a run-time penalty for this ?) None. > > - Make str a subclass of unicode (or vice versa). This can't be done > > because subclassing requires implementation inheritance, in > > particular the instance structure layout must overlap. Also, this > > would make it hard to check for either str or unicode. > > -0. This would be hard to get right because the two objects use a > very different struct layout. Could be an option in the long run though. I tried to explany that I already gave it a -1. ;-) > > - Create a new service function, IsString(x) or isString(x) or > > isstring(x), that's a shortcut for "isinstance(x, str) or > > isinstance(x, unicode)". The question them becomes where to put > > this: as a builtin, in types.py, or somewhere else... > > -1. This mechanism can not be extended by e.g. UserStrings. Good point. There's still Neil's isinstance(x, (str, unicode)) which gives the programmer more freedom: maybe some function wants to support lists and tuples but not all sequences. I'm currently +1 on introducing names for abstract base classes *and* extensing isinstance()'s API. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4