On 5/17/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Michael Chermside" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > However, this is more of a practice than a prohibition... it IS > > possible to modify existing classes in Python. > > If the class is defined/written in Python. > > > Unfortunately, for implementation reasons you can't modify most > > built-in (and some user-defined) classes in this fashion: > > Being able to add Python-coded functions as methods of compiled C-coded > types/classes (builting or otherwise) would require some wrapping machinery > that would slow down normal usage.
I don't think so. There are two reasons why I currently forbid modifying built-in types: (a) I worry about a user modifying a built-in type to fit their needs (e.g. redefining dict.__getitem__ to return None if the value isn't there) and thereby breaking a library module they use (perhaps indirectly), and having a hell of a time debugging their self-inflicted problem. (b) CPython supports multiple interpreters (although you have to write C code to benefit from this feature -- mod_python does this I believe). The built-in types are currently shared between all interpreters. Thus changes made in one interpreter, even if benign (not of the nature described in (a)), affect all interpreters, which would be bad. I suppose if we decided we really didn't care about (a), we could write some code that created pristine copies of all built-in types when a new interpreter is created. Extension modules would also require some kind of hack but this could all be solved if we really wanted to. Or we could stop caring about multiple interpreters -- they are not as successful as I expected when I added them. (However, Brett's thesis on sandboxing may revive them -- or provide an alternative.) Some people believe that (a) won't be a problem in practice because few people would *modify* the built-in types; instead, they would just *add* stuff, and make very sure to avoid name conflicts. Suppose built-in types were modifiable, then all sorts of type registries could be replaced by special methods. The standard library could use __foo__ as naming convention. Third party code could use __foo or some other naming convention e.g. package__subpackage__module__pick_your_name_here. This strategy (like overloaded/generic functions, BTW) means that subclasses by default get the same treatment as the base class that defines the special method. This is different than the type registries currently used e.g. by pickle.py and copy.py. (For example, pickling has a special typecode for ints which shouldn't be used for a subclass of int.) But I think that could be overcome by checking for an exact type match, and otherwise doing something more generic. Some built-in types already have such shortcuts in their __new__ methods. And it would only affect a few very popular types that get special treatment anyway. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
