[zope.interface bug] Re: [Zope-dev] "zope.interface" confuses Python

Dieter Maurer dieter at handshake.de
Tue Jan 8 15:23:35 EST 2008


Jim Fulton wrote at 2008-1-7 16:04 -0500:
>...
>> If "__implements__" is inherited, why is "__provides__" not
>> inherited?
>
>__provides__ (in this context) is a class attribute.  I don't support  
>(and don't want to support) inheritance between class objects.

Where can I read about the "__provides__" semantics?
Where is it documented?


Python does support class attribute inheritance as can be seen
by this small transscript:

>>> class C(object): x=1 # class attribute "x"
...
>>> class CD(C): pass
...
>>> CD.x # class attribute "x" inherited by "CD"
1


Why do you think that "zope.interface" should not support
class attribute inheritance.

> ....
>> This fails for classes magically stuffed with a "__provides__"
>> descriptor.
>
>It also fails for any descriptor that sometimes raises attribute  
>errors.  Someone should report this as an inspect bug.  This would be  
>so easy to fix.

True -- but if they are not far more ready to admit a bug,
there is little chance that this gets fixed.

> ....
>I suggest monkey-fixing inspect.getmembers.  This is a small function  
>that should be easy to replace with a non-broken version.

This is already done. "dm.reuse" allows in many cases to
fix functions without code duplication.


Nevertheless, I am convinced to face a bug both in "zope.interface"
as well as in "inspect".

> ....

>>> My main gripe with the way this works is that classes get mutated.   
>>> If
>>> I ever redo this someday, I'd use a data structure external to the
>>> classes.  Modifying the classes was a mistake.
>>
>> Yes. That, too, would have avoided the bug.
>
>
>Yes, it would have avoided the inspect bug.  IMO, it would also have  
>been cleaner. If someone wants to volunteer to change it, I'll try to  
>provide some oversight. Unfortunately, it's not a small task, which is  
>why I'm not volunteering to do it.

You probably have already a notion about the semantics of "__provides__".

If someone else should change anything with it, he will need
a precise understanding what "__provides__" means, which properties
is has and which not.

Moreover, backward compatibility needs to be taken into account.
When "__provides__" stops to be an ill behaving class attribute,
then this obviously is a change in behavior.



-- 
Dieter


More information about the Zope-Dev mailing list