[Python-Dev] flextype.c -- extended type system
Guido van Rossum
Sun, 15 Sep 2002 15:43:38 -0400
> [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.
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.
> 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/)