[Python-3000] State of the object system

[Guido van Rossum]

On 5/17/06, Terry Reedy <tjreedy at udel.edu> wrote:
>
> "Michael Chermside" <mcherm at mcherm.com> wrote in message
> news:20060517053503.oq4mtmzuzmv4s4sw at login.werra.lunarpages.com...
> > 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/)