The Don Beaudry/Jim Fulton hack

[Dave Abrahams]

In article <1265560092-4227862 at hypernet.com> , "Gordon McMillan" 
<gmcm at hypernet.com> wrote:

> Dave Abrahams wrote:
>>
>> I've recently been crawling through the source code (trying to
>> understand what all those fields in PyTypeObject really do), and
>> stumbled across an explanation for what I had read about being
>> able to subclass a type extension in Python: there's special code
>> to make this possible!
>
> Not really. That special code allows you to take over the
> building of a new instance from Python. Subclassing a type
> takes a whole lot of C code.

Yes, really.
Even with a whole lot of 'C' code, you couldn't subclass a type extension
without that bit of special code. That bit of special code is what makes it
possible.

>> I think: it would be cool to experiment with this before writing
>> any C code, just to make sure I understand it. So I fire up
>> Python. Since the special code is never entered if the base is a
>> real class (not shown), I figure it has to be an instance:
>> otherwise, how could it have an attribute called "__class__"?
>
> Correct.
>
>> >>> class Empty: pass
>> ...
>> >>> base = Empty()
>> >>> base.__class__ = stupid_class
>> Traceback (innermost last):
>>   File "<input>", line 1, in ?
>> TypeError: __class__ must be set to a class
>> >>>
>
> Nope. The above magic is invoked when the "class" statement
> is run. So the key is
>
> class MyClass(magicinstance):
>
> That is, you "derive" from an instance. The magicinstance has
> nothing to do with the result. It's the magicinstance's class
> that provides the magic.

I understood all that. I just forgot that attributes of the class object are
reflected in its instances. It would have been more helpful to nudge me in
this direction, instead:

class Empty:
    __class__ = stupid_class

> IOW, this was an easy way to test
> out an experimental feature, not an axiom of the object model.

Yes; I was intending to explore it experimentally before I started writing
C++ code.

> Look at Demo/metaclasses.
>
>
>> Finally, another point. It is now possible to make extension
>> classes which walk, talk, and smell just like built-in classes
>
> Not at all.

In what sense "not at all"?

> Making a type subclassable means bridging the two
> different "method" mechanisms. Types have slots, classes /
> instances have magic dictionaries.

Certainly I can make an extension types which have magic dictionaries, just
like classes and instances do (not that I would waste the effort on
something so uninteresting).

> Take a look at
> ExtensionClass from Digital Creations (comes with Zope).
> Notice that it reimplements 99% of everything, and only types
> of the ExtensionClass type are subclassable (so you still can't
> subclass lists or dictionaries).

I didn't claim to be able to subclass the built-in types. All I said was
that I could make a system of class and instance extension types which are
arbitrarily similar to built-in classes and instances, up to the point where
somebody calls is_instance() or uses type(). Then the whole system is
exposed. I don't think there's any way around the latter, but I'd prefer it
if the former could be made to work.

-Dave