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

[Guido van Rossum]

> [Christian Tismer]
> 
> <snip>
> > 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.

[Brett Cannon]
> That sounds great.  Anything to make coding C extensions easier.

Brett, may I politely suggest that you try writing C extensions first
before claiming it needs to be made easier?

Christian's additions (as far as I understand them :-) are mostly
intended for very esoteric situations.

> > 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.
> <snip>
> 
> 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?

Alas, it would cause a major slowdown if this was the only way to
provide heavily-used operations like __add__ and __getitem__.  Most of
the machinery to allow this probably already exists, but I wouldn't
recommend using it.  Also, you'd have to provide two implementations
for binary operators, e.g. __add__ and __radd__.

> 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.  =)

You could've picked a simpler extension to try to modify. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)