[Python-Dev] flextype.c -- extended type system

Brett Cannon drifty@bigfoot.com
Sun, 15 Sep 2002 12:33:24 -0700 (PDT)

[Christian Tismer]

> For your own, non-magic methods, there was not support, yet.
> Sure, you could override your methods, but you needed
> extra machinery to keep track of the methods, to find out
> which to call when, and so on.
> The proper way to store extra info about methods is to
> put this info into the type object itself. This was not
> possible before my patch. You could help yourself my
> extending some of the existing method tables, but this
> is hackish.

That sounds great.  Anything to make coding C extensions easier.

> I didn't care of the magic slots at all. I think they don't need
> to be changed, but I will have a look at it.

Part of the reason I asked about the magic slots is that I personally
think it would be great if you didn't have to use the specific struct
slots for magic slots but instead were called based on their name in
Python.  That way you would not have to view Include/object.h every time
you wanted to use one of the magic methods; you could just add it just
like any other method and just give it a Python name that matched its
magic method name.  The obvious drawback is you would lose compiler
checking that the arguments were correct for the method.  But wouldn't
this simplify keeping binary-compatibility if it was used since the struct
would be pruned down significantly?

I don't know how much of a stumbling block this all is for newbies, but I
know when I looked at extending sre's pattern objects to add a
__contains__ method it took me a little while to find where the slot was
and what all the macros were for.  But that might also be because I didn't
read the C extension docs and just dove in.  =)