[Python-3000] Method to populate tp_* slots via getattr()?

[Guido van Rossum]

On Wed, Apr 2, 2008 at 6:30 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> One of the issues with porting to Py3k is the problem that __getattr__
>  and __getattribute__ can't reliably provide special methods like __add__
>  the way __getattr__ could with classic classes. (As first noted by Terry
>  Reedy years ago, and recently seeing some new activity on the bug
>  tracker [1])
>
>  The culprit here is the fact that __getattribute__ and its associated
>  machinery is typically never invoked for the methods with dedicated tp_*
>  slots in the C-level type structure.

Well, yes, this is all an intentional part of the new-style class design.

>  What do people think of the idea of providing an extra method on type
>  objects that goes through all of the C-level special method slots, and
>  for each one that isn't currently set, does a getattr() on the
>  associated special name and stores the result (if any) on the current
>  type object?

Does a getattr on what? Since you seem to be thinking specifically of
proxies here, I'm thinking you're doing a getattr on an *instance* --
but it seems wrong to base the *type* slots on that.

>  When converting a proxy class that relies on __getattr__ from classic

Can you show specific code for such a proxy class? I'm having a hard
time imagining how it would work (not having used proxies in a really
long time...).

> to new-style, all that would then be needed is to invoke the new method on
>  the class object after defining the class (a class decorator or
>  metaclass could be provided somewhere to make this a bit tidier).

Hm. So you are thinking of a proxy for a class?!?!

Note that if you set a class attribute corresponding to a special
method (e.g. C.__add__ = ...) the corresponding C slot is
automatically updated, so you should be able to write a class
decorator or mixin or helper function to do this in pure Python,
unless I completely misunderstand what you're after.

>  This seems a lot cleaner than expecting everyone that implements a proxy
>  object to maintain there own list of all of the relevant special
>  methods, and locates the implementation support in an area of the code
>  that already has plenty of infrastructure dedicated to keeping Python
>  visible attributes in sync with the C visible tp_* slots.

How many proxy implementations does the world need? Maybe we should
add one to the stdlib?

>  Thoughts? Altenative ideas? Howls of protest?

No, so far just a bit of confusion. :-)

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