Zope2 porting failure in Products
Hi all, During the porting of Zope2 I have now stuck with a failure in the module Products. in the file.. /home/user-name/ztrunk25/lib/python/Products/Five/browser/tests/aqlegacy.py in line no: 96 assert self.aq_base == self the comparison results True in python2.4 but the same comparison yeilds the result False in python2.5 A similar problem was there in the module Acquisition which we could manage to get fixed by making change in the file_Acquisition.c I hope the code for this assert (used in line "assert self.aq_base == self" ) is defined for zope and can be fixed with not so much effort. Can any one suggest where why these different versions are showing two results. Or the file or code segment that does this assertion .
Hey, On Mon, Jul 21, 2008 at 8:40 AM, ranjith kannikara <ranjithkannikara@gmail.com> wrote:
During the porting of Zope2 I have now stuck with a failure in the module Products. in the file.. /home/user-name/ztrunk25/lib/python/Products/Five/browser/tests/aqlegacy.py in line no: 96 assert self.aq_base == self
That's a scary result and means there's something different in the way acquisition is handled in python 2.5. Sidnei, can you help the students dig into this one? [snip]
I hope the code for this assert (used in line "assert self.aq_base == self" ) is defined for zope and can be fixed with not so much effort. Can any one suggest where why these different versions are showing two results. Or the file or code segment that does this assertion .
I don't know why there is a different result, but it's important to find out. Otherwise all sorts of assumptions might be broken! That said, it's in a module aqlegacy.py, I wonder what the purpose of that module is. Regards, Martijn
Martijn Faassen wrote:
On Mon, Jul 21, 2008 at 8:40 AM, ranjith kannikara <ranjithkannikara@gmail.com> wrote:
[snip]
I hope the code for this assert (used in line "assert self.aq_base == self" ) is defined for zope and can be fixed with not so much effort. Can any one suggest where why these different versions are showing two results. Or the file or code segment that does this assertion .
I don't know why there is a different result, but it's important to find out. Otherwise all sorts of assumptions might be broken! That said, it's in a module aqlegacy.py, I wonder what the purpose of that module is.
The module aqlegacy.py was added by philiKON and me and fakes Acquisition support (by providing all required methods) for classes not inheriting from Acquisition anymore. This was part of the AQ vs. __parent__ merge. For example Five BrowserView's don't inherit from any Acquistion base classes anymore, but for backwards compatibility we still provide the methods (aq_parent, aq_inner, ...) on the class, since lots of code out in the wild might use them. If the assert statement fails now, the actual cause needs to be investigated and fixed. Hanno
On Mon, Jul 21, 2008 at 9:01 PM, Hanno Schlichting <plone@hannosch.info> wrote:
Martijn Faassen wrote:
On Mon, Jul 21, 2008 at 8:40 AM, ranjith kannikara <ranjithkannikara@gmail.com> wrote:
[snip]
I hope the code for this assert (used in line "assert self.aq_base == self" ) is defined for zope and can be fixed with not so much effort. Can any one suggest where why these different versions are showing two results. Or the file or code segment that does this assertion .
I don't know why there is a different result, but it's important to find out. Otherwise all sorts of assumptions might be broken! That said, it's in a module aqlegacy.py, I wonder what the purpose of that module is.
The module aqlegacy.py was added by philiKON and me and fakes Acquisition support (by providing all required methods) for classes not inheriting from Acquisition anymore.
This was part of the AQ vs. __parent__ merge. For example Five BrowserView's don't inherit from any Acquistion base classes anymore, but for backwards compatibility we still provide the methods (aq_parent, aq_inner, ...) on the class, since lots of code out in the wild might use them.
Hi Hanno, Thanks for your reply. We are still wandering in the code to get the reason of this failure of the 'assert' . We cant even figure out whether the cause for the failure is in the module Acquisition itself or not. Can you say whether the failure is in the module Acquisition?? If not can you help us in figuring out the reason of this failure?
If the assert statement fails now, the actual cause needs to be investigated and fixed.
Hanno
Hello everyone, Thanks for the suggestions you have made. Any way we have just managed to fix the failure by bringing the change we have made in the implicit compare function in Acquisition to the Explicit comparison also. Thanks Ranju. On Mon, Jul 21, 2008 at 9:25 PM, ranjith kannikara <ranjithkannikara@gmail.com> wrote:
On Mon, Jul 21, 2008 at 9:01 PM, Hanno Schlichting <plone@hannosch.info> wrote:
Martijn Faassen wrote:
On Mon, Jul 21, 2008 at 8:40 AM, ranjith kannikara <ranjithkannikara@gmail.com> wrote:
[snip]
I hope the code for this assert (used in line "assert self.aq_base == self" ) is defined for zope and can be fixed with not so much effort. Can any one suggest where why these different versions are showing two results. Or the file or code segment that does this assertion .
I don't know why there is a different result, but it's important to find out. Otherwise all sorts of assumptions might be broken! That said, it's in a module aqlegacy.py, I wonder what the purpose of that module is.
The module aqlegacy.py was added by philiKON and me and fakes Acquisition support (by providing all required methods) for classes not inheriting from Acquisition anymore.
This was part of the AQ vs. __parent__ merge. For example Five BrowserView's don't inherit from any Acquistion base classes anymore, but for backwards compatibility we still provide the methods (aq_parent, aq_inner, ...) on the class, since lots of code out in the wild might use them.
Hi Hanno,
Thanks for your reply. We are still wandering in the code to get the reason of this failure of the 'assert' . We cant even figure out whether the cause for the failure is in the module Acquisition itself or not.
Can you say whether the failure is in the module Acquisition??
If not can you help us in figuring out the reason of this failure?
If the assert statement fails now, the actual cause needs to be investigated and fixed.
Hanno
participants (3)
-
Hanno Schlichting -
Martijn Faassen -
ranjith kannikara