Magic methods in extension types

[Jacek Generowicz]

Michael Hudson <mwh at python.net> writes:

> Jacek Generowicz <jacek.generowicz at cern.ch> writes:
> 
> > Michael Hudson <mwh at python.net> writes:
> > 
> > > Jacek Generowicz <jacek.generowicz at cern.ch> writes:
> > > 
> > > > Michael Hudson <mwh at python.net> writes:

> > > and for new-style classes much hair in typeobject.c:type_new and
> > > therein called functions.  Extension types don't go through type_new
> > > and are expected to go the other way round, in a sense: define
> > > something in tp_as_number->nb_inplace_add and a wrapper called
> > > __iadd__ will be created for you.
> > 
> > Yuk.
> 
> Why?

Partly because I misread (thinking that *I* had to write hairy stuff
for it to work), and partly because the dichotomy offends my sense of
symmetry, beauty, coherence, cleanlyness etc.

> > You are, in summary, saying that by _far_ the simplest way of adding
> > __iadd__ to an extenion type is via tp_as_number->nb_inplace_add,
> > aren't you.
> 
> Yes.  I'm surprised at your apparent surprise, but then I've had my
> head in the guts of Python's implementation for quite some time
> now...

... while I try to keep out of there. (I appreciate Python for its
ability to hide unimportant low-level details, not for it being a C
program; if I wanted to program in a low-level language, I wouldn't
need Python ... unless it would be to play with implementation details
of Python itself: you realize that I'm eagerly waiting for PyPy to
deliver :-)

> implementing types in C is really quite different from
> implementing them in Python, something which has only become
> surprising since 2.2...

Yes, I was blindly hoping that type-class unification would have made
implementing extension types look more like implementing Python types.

Anyway, it's clear what I have to do. Thanks.