Does Python really follow its philosophy of "Readability counts"?

Michele Simionato michele.simionato at
Wed Jan 28 06:33:08 CET 2009

On Jan 27, 9:13 pm, Mark Wooding <m... at> wrote:
> I'm referring to a number of features:
>   * Redefinition of classes, yes.  Interactive development is very
>     frustrating without this.  Thanks for that link, by the way!
>   * CHANGE-CLASS to change the class of instances.  This is more than
>     just assigning to mumble.__class__, since it correctly initializes
>     the slots present in the new class which were absent in the old.
>   * And all of the fancy MOP tricks you can play: inventing new slot
>     classes; messing with class-precedence-list orderings (Python's
>     MRO).
> It's a shorter list than I'd hoped!  Still, these features kind of
> multiply up.  You can redefine a class using a new metaclass and slot
> options, and all the instances are updated, for example.
> Anyway, I think I exaggerated when I said that CLOS was `much more
> dynamic', but it is /somewhat/ more dynamic, and still amenable to
> optimization; since my point was that dynamism in a language isn't
> necessarily antithetical to compilation, that's still sufficient.
> Thanks for keeping me honest!

Fair enough. My view is that even if apparently CLOS has some
additional feature over the standard Python object model, in practice
you can implement the same features in Python with some metaclass
trick, *without the need to change the language at the C level*. This
is why I think the Python object model is at least as dynamic as CLOS.
In particular, a metaclass can implement the functionality CHANGE-
CLASS, can mess with the __bases__ and with the MRO, etc.
If you want to see an example of how much the Python object model can
be perverted, you may be interested in this module of mine:

The module changes the standard object system from a multiple
inheritance one to a single inheritance one plus traits.

                   Michele Simionato

More information about the Python-list mailing list