Really stupid question regarding PEP 252 and type/class unification

Bengt Richter bokr at accessone.com
Thu Aug 23 15:30:44 EDT 2001


On Thu, 23 Aug 2001 16:33:25 +0200, "Alex Martelli" <aleax at aleax.it> wrote:

>"Russell Turpin" <russell_turpin at hotmail.com> wrote in message
>news:8a12e538.0108230607.30481024 at posting.google.com...
>    ...
>>     class MyInt(type(0)):
>>         pass
>>
>>     myInt = MyInt()
>>     myInt = 5                     # Will this work?
>
>Sure it will work: it re-binds name myInt to something
>different just before, exactly as it always did.  WHATEVER
>myInt was before the
>    myInt = 5
>has absolutely NO relevance.
>
ISTM this is a matter of defining the semantics of the
assignment/binding expression
    lhs = rhs
Is it cast in concrete *for always and forever* that the
old binding of the lhs will *always* be discarded in favor of a new
binding to the rhs without regard to the previous binding?

IOW, one could conceive of a check for an attribute of the old
binding's object which if present would mean that the old object
gets to handle the reference to the new rhs and leave the old
binding alone. E.g.,

    class C:
        def __instance_rebinding_preemption__(self,x):
            print 'C instance is controlling instance = ',x,'binding.'
        def __class_rebinding_preemption__(self,x):
            print 'class C is controlling C = ',x,'binding.'

    c=C()
    c=5
would =>
    C instance is controlling instance = 5 binding.
and
    c
would =>
    <__main__.C instance at XXXXXXXX>
and
    C=5
would =>
    class C is controlling C = 5 binding.
Preemption of rebinding of a metaclass instance would work the same way
as any other instance.

This scheme would amount to a permanent binding for a symbol in a particular
scope, until something deleted the relevant binding preemption method.





More information about the Python-list mailing list