iterating over class without __iter__ but with __getitem__ raises AttributeError:__iter__
Hi All, The context for this is trying to get ParsedXML 1.5 running on Zope 2.12 under Python 2.5 (don't ask why!) Anyway, ParsedXML has a class: class ManageableNodeList(ManageableWrapper, DOMProxy.NodeListProxy, Acquisition.Implicit): "A wrapper around a DOM NodeList." meta_type = "Manageable NodeList" # redefine to get back the [] syntax with acquisition, eh? def __getslice__(self, i, j): return self.wrapNodeList(self._node.__getslice__(i,j)) # redefine to get back the [] syntax with acquisition, eh? def __getitem__(self, i): return self.wrapDOMObj(self._node.__getitem__(i)) If you try and iterate over an instance of this class, you get an AttributeError: __iter__. This doesn't make a lot of sense, since you *don't* get an error like that if you iterate over an instance of: class X: def __getitem__(self,i): return 1 I'm wondering there's some ExtensionClass or similar weirdness happening here? (It didn't used to happen under Zope 2.9/Python 2.4) cheers, Chris PS: I have a f'ing horrible workaround for how: ... def __iter__(self): return SillyIterator(self) class SillyIterator: def __init__(self,mnl): self.mnl = mnl self.i = 0 def next(self): try: e = self.mnl[self.i] except IndexError: raise StopIteration self.i+=1 return e -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2009-4-13 03:14 +0100:
The context for this is trying to get ParsedXML 1.5 running on Zope 2.12 under Python 2.5 (don't ask why!)
Anyway, ParsedXML has a class:
class ManageableNodeList(ManageableWrapper, DOMProxy.NodeListProxy, Acquisition.Implicit): "A wrapper around a DOM NodeList." meta_type = "Manageable NodeList"
# redefine to get back the [] syntax with acquisition, eh? def __getslice__(self, i, j): return self.wrapNodeList(self._node.__getslice__(i,j))
# redefine to get back the [] syntax with acquisition, eh? def __getitem__(self, i): return self.wrapDOMObj(self._node.__getitem__(i))
If you try and iterate over an instance of this class, you get an AttributeError: __iter__. This doesn't make a lot of sense, since you *don't* get an error like that if you iterate over an instance of:
class X: def __getitem__(self,i): return 1
I'm wondering there's some ExtensionClass or similar weirdness happening here?
(It didn't used to happen under Zope 2.9/Python 2.4)
It does not go wrong with Zope 2.11/Python 2.4, neither. Maybe, changes done for Python 2.5/2.6 compatibility broke something. Here is a simpler script to check for problems: from Acquisition import Implicit class C(Implicit): def __getitem__(self, i): return self.l[i] l=[1,2,3] c=C() iter(c) list(_) c2=C().__of__(c) iter(c2) list(_) -- Dieter
Dieter Maurer wrote:
It does not go wrong with Zope 2.11/Python 2.4, neither. Maybe, changes done for Python 2.5/2.6 compatibility broke something.
Here is a simpler script to check for problems:
Indeed:
class C: ... l=[1,2,3] ... def __getitem__(self, i): ... return self.l[i] list(_)
... from Acquisition import Implicit class C(Implicit):
c=C() def __getitem__(self, i): iter(c)
<iterator object at 0xb7db8ecc>
list(_) iter(c) [1, 2, 3]
list(_)
from Acquisition import Implicit iter(c2) list(_) class C(Implicit): ... l=[1,2,3] ... def __getitem__(self, i): ... return self.l[i] ... c=C() iter(c) <iterator object at 0xb7dbb38c> list(_) [1, 2, 3] c2=C().__of__(c) iter(c2) Traceback (most recent call last): File "<console>", line 1, in <module> AttributeError: __iter__
cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
If you try and iterate over an instance of this class, you get an AttributeError: __iter__. This doesn't make a lot of sense, since you *don't* get an error like that if you iterate over an instance of:
class X: def __getitem__(self,i): return 1
The change you are interested in is probably: http://svn.zope.org/Zope/trunk/lib/python/Acquisition/_Acquisition.c?rev=949... Acquisition now proxy real iteration via __iter__ correctly (it didn't do that before). What is missing from that change is probably the fallback to the __getitem__ protocol, in case the class isn't a real iterator. Hanno
Hanno Schlichting wrote:
The change you are interested in is probably:
http://svn.zope.org/Zope/trunk/lib/python/Acquisition/_Acquisition.c?rev=949...
Acquisition now proxy real iteration via __iter__ correctly (it didn't do that before). What is missing from that change is probably the fallback to the __getitem__ protocol, in case the class isn't a real iterator.
Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13.04.2009 17:58 Uhr, Chris Withers wrote:
Hanno Schlichting wrote:
The change you are interested in is probably:
http://svn.zope.org/Zope/trunk/lib/python/Acquisition/_Acquisition.c?rev=949...
Acquisition now proxy real iteration via __iter__ correctly (it didn't do that before). What is missing from that change is probably the fallback to the __getitem__ protocol, in case the class isn't a real iterator.
Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in?
Since Acquisition is a core module of Zope: the Zope 2 tracker on Launchpad. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknji+wACgkQCJIWIbr9KYxd5ACeO1Sx3ubk9laxtgJsS51w2YRf UJkAnjUV/N52ZAH0KPI1vqZM7MMt0oHD =hk9o -----END PGP SIGNATURE-----
Andreas Jung wrote:
Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in?
Since Acquisition is a core module of Zope: the Zope 2 tracker on Launchpad.
Done: https://bugs.launchpad.net/zope2/+bug/360761 Now, who knows how to fix it? ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
hi chris, Chris Withers wrote:
Andreas Jung wrote:
Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in? Since Acquisition is a core module of Zope: the Zope 2 tracker on Launchpad.
Done:
thanks!
Now, who knows how to fix it? ;-)
since i broke things, i'll try to have a look... andi -- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2.2 released! -- http://plone.org/products/plone/
Chris Withers wrote:
Andreas Jung wrote:
Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in? Since Acquisition is a core module of Zope: the Zope 2 tracker on Launchpad.
Done:
https://bugs.launchpad.net/zope2/+bug/360761
Now, who knows how to fix it? ;-)
this has been fixed in http://svn.zope.org/?view=rev&rev=99191 cheers, andi -- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2.1 released! -- http://plone.org/products/plone/
Andreas Zeidler wrote:
Chris Withers wrote:
https://bugs.launchpad.net/zope2/+bug/360761
Now, who knows how to fix it? ;-)
this has been fixed in http://svn.zope.org/?view=rev&rev=99191
Wonderful, if Chris can confirm this, I'll make a new Acquisition release. Hanno
Hanno Schlichting wrote:
Andreas Zeidler wrote:
Chris Withers wrote:
https://bugs.launchpad.net/zope2/+bug/360761
Now, who knows how to fix it? ;-) this has been fixed in http://svn.zope.org/?view=rev&rev=99191
Wonderful, if Chris can confirm this, I'll make a new Acquisition release.
I've running with a develop copy of the Zope 2 trunk. This has include/Acquisition, but is that actually being used? If not, then why is it included like that? If so, then how do I get it to recompile now that I've svn up'ed my Zope 2 trunk to get Andreas' changes? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Hanno Schlichting wrote:
Andreas Zeidler wrote:
Chris Withers wrote:
https://bugs.launchpad.net/zope2/+bug/360761
Now, who knows how to fix it? ;-) this has been fixed in http://svn.zope.org/?view=rev&rev=99191 Wonderful, if Chris can confirm this, I'll make a new Acquisition release.
I've running with a develop copy of the Zope 2 trunk.
Which doesn't include a develop version of Acquisition. Acquisition is its own package.
This has include/Acquisition, but is that actually being used? If not, then why is it included like that?
These are only the header files of Acquisition. Some of the C extensions of the Zope2 egg depend on those headers.
If so, then how do I get it to recompile now that I've svn up'ed my Zope 2 trunk to get Andreas' changes?
You need to check out Acquisition from its SVN trunk and include it into your environment (develop line in buildout or "python setup.py develop"). Forcing a recompilation of C extensions works via the normal "python setup.py build_ext -i -f" Hanno
Hanno Schlichting wrote:
I've running with a develop copy of the Zope 2 trunk.
Which doesn't include a develop version of Acquisition. Acquisition is its own package.
Ah, okay, I'll pop Acquisition into develop and test before the end of this email ;-)
This has include/Acquisition, but is that actually being used? If not, then why is it included like that?
These are only the header files of Acquisition. Some of the C extensions of the Zope2 egg depend on those headers.
Liar! ;-) If that were true then this wouldn't happened: chris@server2:~/zope$ svn up Zope2/ Fetching external item into 'Zope2/include/Acquisition' U Zope2/include/Acquisition/_Acquisition.c U Zope2/include/Acquisition/tests.py Updated external to revision 99199.
If so, then how do I get it to recompile now that I've svn up'ed my Zope 2 trunk to get Andreas' changes?
You need to check out Acquisition from its SVN trunk and include it into your environment (develop line in buildout or "python setup.py develop"). Forcing a recompilation of C extensions works via the normal "python setup.py build_ext -i -f"
...how would I force recompilation in a buildout environment? Chris PS: It worked, please could you roll the new acquisition egg and update the required version on the Zope 2 trunk? -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Hanno Schlichting wrote:
This has include/Acquisition, but is that actually being used? If not, then why is it included like that? These are only the header files of Acquisition. Some of the C extensions of the Zope2 egg depend on those headers.
Liar! ;-)
Ok, sigh. The external includes more, but only the .h file is actually used from it. Give me an updated Subversion and we can include files instead of directories as externals ;)
If so, then how do I get it to recompile now that I've svn up'ed my Zope 2 trunk to get Andreas' changes? You need to check out Acquisition from its SVN trunk and include it into your environment (develop line in buildout or "python setup.py develop"). Forcing a recompilation of C extensions works via the normal "python setup.py build_ext -i -f"
....how would I force recompilation in a buildout environment?
Via "python setup.py build_ext -i -f" - works in all environments. Deleting the .so files is probably another way.
PS: It worked, please could you roll the new acquisition egg and update the required version on the Zope 2 trunk?
Acquisition 2.12.1 is released and included into Zope 2 trunk. I'm adding the Windows eggs right now. Hanno
Hanno Schlichting wrote:
If so, then how do I get it to recompile now that I've svn up'ed my Zope 2 trunk to get Andreas' changes? You need to check out Acquisition from its SVN trunk and include it into your environment (develop line in buildout or "python setup.py develop"). Forcing a recompilation of C extensions works via the normal "python setup.py build_ext -i -f" ....how would I force recompilation in a buildout environment?
Via "python setup.py build_ext -i -f" - works in all environments. Deleting the .so files is probably another way.
I guess that equates to: bin/buildout setup path/to/setup.py build_ext -i -f ?
PS: It worked, please could you roll the new acquisition egg and update the required version on the Zope 2 trunk?
Acquisition 2.12.1 is released and included into Zope 2 trunk. I'm adding the Windows eggs right now.
Cool, I've tried it out and it works fine. If only Andreas was so responsive ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Hanno Schlichting wrote:
....how would I force recompilation in a buildout environment? Via "python setup.py build_ext -i -f" - works in all environments. Deleting the .so files is probably another way.
I guess that equates to: bin/buildout setup path/to/setup.py build_ext -i -f ?
No. cd <path to develop egg> python setup.py build_ext -i -f There's nothing buildout specific about this. Hanno
Hanno Schlichting wrote:
Chris Withers wrote:
Hanno Schlichting wrote:
....how would I force recompilation in a buildout environment? Via "python setup.py build_ext -i -f" - works in all environments. Deleting the .so files is probably another way. I guess that equates to: bin/buildout setup path/to/setup.py build_ext -i -f ?
No.
cd <path to develop egg> python setup.py build_ext -i -f
There's nothing buildout specific about this.
...but getting the right python can be important enough to do it. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (5)
-
Andreas Jung -
Andreas Zeidler -
Chris Withers -
Dieter Maurer -
Hanno Schlichting