[Twisted-Python] Disturbing aspect of zope.interface
Hi, I know this is not the zope list, but I am encountering this in a twisted project, so I wanted to get some ideas here first. I am finding that zope.interface is like an infectious disease. Here is a simple example: In [35]: import zope.interface as zi In [37]: class A(object): ....: pass In [38]: class IB(zi.Interface): ....: pass In [39]: hasattr(A, '__provides__') Out[39]: False In [41]: # Inheriting from A gives A additional methods In [42]: class B(A): ....: zi.implements(IB) In [43]: hasattr(A, '__provides__') Out[43]: True In [45]: # C is clean of the additional methods In [46]: class C(object): ....: pass In [47]: hasattr(C, '__provides__') Out[47]: False The disturbing thing is that now A (which is just an object) has been hacked on by zope.interface. It has additional methods (__provides__, etc.) that are specific to zope. Summary: If a class A is later subclassed by something B that calls zi.implements, the original class A becomes infected with all the zope.interface stuff. Is there a way to avoid this? Doesn't this seem like a bad idea? Cheers, Brian
On Thu, Oct 8, 2009 at 7:23 PM, Brian Granger <ellisonbg.net@gmail.com>wrote:
I know this is not the zope list
You're right, it's not. Perhaps you could send a message to the interface package development list? https://mail.zope.org/mailman/listinfo/interface-dev The disturbing thing is that now A (which is just an object) has been hacked
on by zope.interface. It has additional methods (__provides__, etc.) that are specific to zope.
Why does this disturb you? Would you feel better if it were called __zope_provides__? Summary: If a class A is later subclassed by something B that calls
zi.implements, the original class A becomes infected with all the zope.interface stuff.
A gets an additional attribute. Its behavior doesn't change in any other way. I don't really see what's wrong with that, unless you have a differing definition of the __provides__ attribute in your code. Is there a way to avoid this? Depending on what your definition of "this" is, there almost certainly is. In the simplest case, you could submit a patch to zope interface. Doesn't this seem like a bad idea?
No.
On Thu, Oct 8, 2009 at 7:23 PM, Brian Granger <ellisonbg.net@gmail.com>wrote:
I know this is not the zope list
You're right, it's not. Perhaps you could send a message to the interface package development list?
Yes, I will do that. I wanted to get an opinion here first from the "users of zope.interface" first though to see if anyone else had run into these things in the wild.
The disturbing thing is that now A (which is just an object) has been
hacked on by zope.interface. It has additional methods (__provides__, etc.) that are specific to zope.
Why does this disturb you? Would you feel better if it were called __zope_provides__?
Maybe a little bit, but name collisions are a minor concern in my case...
Summary: If a class A is later subclassed by something B that calls
zi.implements, the original class A becomes infected with all the zope.interface stuff.
A gets an additional attribute. Its behavior doesn't change in any other way. I don't really see what's wrong with that, unless you have a differing definition of the __provides__ attribute in your code.
...but __provides__ is not exactly a "plain old attribute": * The __provides__ attribute is a descriptor that sometimes raises AttributeError even though it exists. This is how I found all of this. I called dir on my class and __provides__ was listed. But hasattr(cls, '__provides') returned False. I consider this to be a separate bug, but because __provides__ started to appear on all of my classes, I was seeing it *everywhere*. * The internal implementation of __provides__ is handled by a custom __metaclass__ hook. zope.interface tries to be pretty careful in not actually *using* a custom metaclass, but it does set and then later remove the __metaclass__ hook. In my mind, both of these things are in the "unwanted side effect" category.
Is there a way to avoid this?
Depending on what your definition of "this" is, there almost certainly is. In the simplest case, you could submit a patch to zope interface.
That is definitely a likely outcome of this discussion. For now though, I was just wondering if other's had run into this issue. For now, it sounds like not. Cheers, Brian
Doesn't this seem like a bad idea?
No.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Is there a project underway to modernize twisted? I've been bitten a couple times by twisted's use of old-style classes. Now that Jython is finally off the 2.2 branch, is there any real reason to stay backwards compatible? cheers, -Mark -- Mark Visser, Software Director Lumière VFX Email: markv@lumierevfx.com Phone: +1-514-316-1080 x3030
On Thu, Oct 8, 2009 at 7:59 PM, Mark Visser <markv@lumierevfx.com> wrote:
Is there a project underway to modernize twisted?
Yes. The project is called "twisted" :). Personally I find that it is very "modern". I've been bitten a couple times by twisted's use of old-style classes.
Now that Jython is finally off the 2.2 branch, is there any real reason to stay backwards compatible?
Changing a class from old-style to new-style is an incompatible change. The difficulty is that if existing libraries use a particular class and inherit from it, changing the class to be new-style can have effects from changing how their descriptors work to causing an exception when their module is imported. We have a compatibility policy, intended to prevent people's applications from breaking when they upgrade Twisted: http://twistedmatrix.com/trac/wiki/CompatibilityPolicy If old-style classes can be evolved into new-style classes while somehow following this policy, that would be great. The problem is that providing compatibility at this level is time-consuming and difficult. One problem in particular is that we don't want to litter the codebase with lots of "Foo" and "NewFoo" or "Foo2" sitting right next to it, so we would have to think of new names for everything. If you have a particular interest in the new-style vs. old-style problem, please feel free to submit patches! This is one of those areas where we need a continuous stream of small improvements from the community, because it's just too much drudgework for the core team to take care of in our spare time.
On Oct 8, 2009, at 7:59 PM, Mark Visser wrote:
I've been bitten a couple times by twisted's use of old-style classes. Now that Jython is finally off the 2.2 branch, is there any real reason to stay backwards compatible?
I don't see any reason to make this change for twisted running on the 2.x branch of CPython. Switching all the classes in twisted to newstyle before then could break some user's code or tests, and doesn't really provide any benefits as far as I can tell. For Python 3.x, oldstyle classes don't exist, so that'll happen automatically during the conversion. Apparently in PyPy, oldstyle classes are significantly slower than newstyle classes. So it might be interesting for them to force everything in twisted.* to be newstyle classes and see what breaks. :) James
For Python 3.x, oldstyle classes don't exist, so that'll happen automatically during the conversion.
Aha! Let me rephrase that, then: Is there a project underway to port Twisted to Python 3.x? cheers, -Mark -- Mark Visser, Software Director Lumière VFX Email: markv@lumierevfx.com Phone: +1-514-316-1080 x3030
On Oct 8, 2009, at 9:03 PM, Mark Visser wrote:
For Python 3.x, oldstyle classes don't exist, so that'll happen automatically during the conversion.
Aha! Let me rephrase that, then:
Is there a project underway to port Twisted to Python 3.x?
Yes, it's called Twisted. S
Mark, you might find this link helpful: http://stackoverflow.com/questions/172306/how-are-you-planning-on-handling-t... Seems to me that the answer is no, there isn't a serious effort underway to port to Python 3, and there probably won't be for a while. My guess is that porting efforts will be rather pedestrian (e.g., running 2to3 and fixing a few things here and there) for a while until Python 3 gains some momentum, or unless there's a lot of community contributions for it. - Matt On Thu, Oct 8, 2009 at 9:18 PM, Steve Steiner (listsin) < listsin@integrateddevcorp.com> wrote:
On Oct 8, 2009, at 9:03 PM, Mark Visser wrote:
For Python 3.x, oldstyle classes don't exist, so that'll happen automatically during the conversion.
Aha! Let me rephrase that, then:
Is there a project underway to port Twisted to Python 3.x?
Yes, it's called Twisted.
S
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Thu, 2009-10-08 at 21:03 -0400, Mark Visser wrote:
Is there a project underway to port Twisted to Python 3.x?
Not at the moment. Supporting both 2.x and 3.x is harder than it should be, and all of Twisted's users (and almost all Python users) use 2.x. -Itamar
On 01:03 am, markv@lumierevfx.com wrote:
For Python 3.x, oldstyle classes don't exist, so that'll happen automatically during the conversion. Aha! Let me rephrase that, then:
Is there a project underway to port Twisted to Python 3.x?
It would be misleading to characterize any part of Twisted development as "a project underway". Twisted is a project, certainly. It may even be underway itself. Beyond that point, I don't think the metaphor is terribly useful or applicable. People work on Twisted. Sometimes they do it with a long term plan. More often than not, they just have a feature they want to add or a bug they want to fix. However, if I were to make up a plan for porting Twisted to Python 3.x, then the first part of that plan would be to fix all of the failing tests reported here: http://buildbot.twistedmatrix.com/builders/python-3k- warnings/builds/203/steps/trial/logs/problems These are tests which fail when Twisted's test suite is run with the -3 option on Python 2.6. Tickets for these failures and patches fixing them would be greatly appreciated. Once that's out of the way, it will make sense to talk about what the next step is. Jean-Paul
On Fri, Oct 09, 2009 at 03:45:02AM -0000, exarkun@twistedmatrix.com wrote:
However, if I were to make up a plan for porting Twisted to Python 3.x, then the first part of that plan would be to fix all of the failing tests reported here:
http://buildbot.twistedmatrix.com/builders/python-3k- warnings/builds/203/steps/trial/logs/problems
These are tests which fail when Twisted's test suite is run with the -3 option on Python 2.6. Tickets for these failures and patches fixing them would be greatly appreciated.
I found ticket 2484 which is (I believe) about making Twisted translatable to Python 3.x with the stock 2to3 tool: http://twistedmatrix.com/trac/ticket/2484 I've added a comment about all the DeprecationWarnings issued by Twisted's test suite when run under Python 2.6's 3.x-compatibility warning mode; there's an awful lot more than just the 24 that cause test failures. I've also filed a bug about fixing one of the warnings mentioned, the one about has_key() being removed in 3.x: http://twistedmatrix.com/trac/ticket/4053 There's a few other warnings for which cleanup patches would be a good lazy-afternoon effort. :)
participants (9)
-
Brian Granger -
exarkun＠twistedmatrix.com -
Glyph Lefkowitz -
Itamar Turner-Trauring (aka Shtull-Trauring) -
James Y Knight -
Mark Visser -
Matt Perry -
Steve Steiner (listsin) -
Tim Allen