Yes, the paper talks mostly about how things will be when you use the
extentions. The version I am using in my current project is actually
still using Python-1.0.2, but that should change soon.
Users of the extentions should notice very little difference between
standard classes and those written with the extentions. The only
differences will be intentional on the part of the extention writter
creating built-in classes. Sub-classing still follows the same
familar pattern:
class MyClass(BaseClass):
pass
The only difference is that the BaseClass might have been implemented
in C.
The way I like to think about the class statement is to say that when
executed, it (the class statement) creates a new instance of a
meta-class (a class). The only non-obvious part (IMHO) is the
determination of which meta-class to instantiate. Even though it
might not be obvious, it is simple. The class statement is creating a
new instance of the class of BaseClass. It might be helpful to look
at a different yet equivalent way of writing the same statement.
MyClass = type(BaseClass)('MyClass', (BaseClass,), {})
Here we are asking BaseClass for its type and then calling that with
three parameters: the name of the new class, the tuple of base
classes, and dictionary. Since the type of BaseClass is itself a
class (actually a meta-class) it responds to the function call
discipline by returning an instance of itself. In this case, that
instance is a class named 'MyClass' with a base class of 'BaseClass'
and no methods (the empty dictionary). Of course in pratice, the
dictionary would actually contain methods and other objects as well.
The Python interpreter takes everything indented under the class
statement and puts it into a dictionary that is then passed to
meta-class along with the name and tuple of base classes.
> And is it likely that this class system will at some point become a
> standard part of the Python language? How much additional code does this
> implementation need, in comparison to the current class implementation?
This question would be better answered by Guido. But I can say that
Guido has made quite a few changes to Python's implementaton to allow
my extentions to be "dropped in" just like any other extention.
The current class implementation remains intact. You can think of it
as just one of many possible meta-class implementaions. When defining
a sub-class, if you leave off the tuple of base classes, you will get
Guido's meta-class by default. I have a meta-class implementation of
my own that is a bit different from Guido's. It uses a read-only
attributes list, so assigning to a non-existent attribute will
generate an exception rather than create the attribute. This allows
its instances to be more memory efficient and have a memory layout
that can be mapped directly to a C structure. That is not to say that
this is better, but only that it might be better in certain
situations. My extentions will let you, the extention writer, make
these decisions for yourself.
These extentions are not small. The last time I checked it was
somewhere around 15,000 lines of code. But it does allow for doing
quite a bit more than simply writing built-in classes. Unfortunately
there is also a bit of overlap in functionality with the Python
implementation. My extentions are essentially a binary compatible
rewrite of Guido's type system.
-- Donald Beaudry DataViews Corporation Software Engineer 47 Pleasant Street don@dvcorp.com Northampton, MA 01060 "So much code, so little time..."