[Python-Dev] Object customization (was: Arbitrary attributes on funcs and methods)

[Vladimir Marangozov]

Gordon McMillan wrote:
> 
> [VM] 
> > As long as we discuss customization of objects with builtin types,
> > the "inconsistency" stays bound to classes and instances. Add modules
> > if you wish, but they are just namespaces. This proposal expands
> > the customization inconsistency to functions and methods. And I am
> > reluctant to see this happening "under the hood", without a global
> > vision of the problem, just because a couple of people have abused
> > unprotected attributes and claim that they can't do what they want
> > because Python doesn't let them to.
> 
> Can you please explain how "consistency" is violated?
>  

Yes, I can.

To start with and to save me typing, please reread the 1st section of
Demo/metaclasses/meta-vladimir.txt  about Classes.

-------

Now, whenever there are two instances 'a' and 'b' of the class A,
the first inconsistency is that we're allowed to assign attributes
to these instances dynamically, which are not declared in the class A.

Strictly speaking, if I say:

>>> a.author = "Guido"

and if 'author' is not an attribute of 'a' after the instantiation
of A (i.e. after a = A() completes), we should get a NameError.

It's an inconsistency because whenever the above assignment succeeds,
'a' is no more an instance of A. It's an instance of some other class,
because A prescribes what *all* instances of A have in *common*.

So from here, we have to find our way in the object model and live
with this 1st inconsistency.

Problem: What is the class of the singleton 'a' then?
         Say, I need this class after the fact to build another society
         of objects, i.e. "clone" 'a' a hundred of times, because 'a'
         has dozens of attributes different than 'b'.

To make a long story short, it turns out that we can build a Python
class A1, having those attributes declared, then instantiate A1
hundreds of times and hopefully, let 'a' find its true identity with:

>>> a.__class__ = A1

This is the key of the story. We *can* build, for a given singleton,
its Python class, after the fact. And this is the only thing which
still makes the Python class model 'relatively consistent'!

If it weren't possible to build that class A1, it would have been
better to stop talking about classes and a class model in Python.
("associations of typed structures with per-type binding rules"
would have probably been a better term).

Now to the question: how "consistency" is violated by the proposal?

It is violated, because actually we *can't* build and restore the class,
after the fact, of a builtin object (a funtion 'f') to which we add user
attributes. We can't do it for 2 reasons, which we hope to solve in Py3K:

1) the class of 'f' is implemented in C
2) we still can't inherit from builtin classes (at least in CPython)

As a consequence, we can't actually build hundreds of "clones" of 'f' by
instantiating a class object. We can build them by adding manually
the same attribute, but this is not OO, this is just 'binding to
a namespace'.

This is the true reason on why this fragile consistency is violated.

Please, save me the trouble to expose the details you're missing,
to each of you, where those details are omitted for simplicity.

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252