[Zope-dev] zope.interface: verifyObject vs properties
There has been a problem with zope.interface's verifyObject function that occurs in conjunction with Python properties: when verifyObject checks for the presence of an object's attribute, it does so by using hasattr() which in turn tries a getattr() call. If the attribute is implemented as a property, this may raise an exception which will be masked by hasattr() due to a bare except: clause. One scenario where this is a problem is a property that performs some component lookup which will succeed at application runtime but not in unit tests where verifyObject is commonly used. While it has also been argued that behaviour so complex that it may raise an Exception should not be implemented as a property in the first place, we believe that verifyObject should handle this case better than it currently does. A possible fix would be to add an additional check for a data descriptor on the object's class if the hasattr() test returns False. Are there any objections against modifying verifyObject in this way? Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Tue Oct 14 11:00:00 2008 UTC to Wed Oct 15 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Oct 14 20:54:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-October/010315.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Oct 14 20:55:53 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-October/010316.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Oct 14 20:57:24 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-October/010317.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Oct 14 20:58:54 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-October/010318.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Oct 14 21:00:24 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-October/010319.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
On 15.10.2008 14:25 Uhr, Martijn Faassen wrote: Sidnei da Silva wrote: On Tue, Oct 14, 2008 at 2:16 PM, Andreas Jung[EMAIL PROTECTED] wrote: Thanks for starting the discussion. Going for Python 2.6 also requires that we get the ZCA running on top of Python 2.6 until some time next year. FWIW, that's what I've been working on. There's enough of the the ZCA working on Python 2.6 to run Zope 2. Would anything else be needed? I would say we are pretty much done as far as Zope 2 is concerned. Concerning the component architecture or the entire port? If the latter, what about the security review for untrusted code? You mean the review of RestrictedPython? Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:[EMAIL PROTECTED] title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Andreas Jung wrote: RestrictedPython: I talked with Alan Runyan about this topic at the Plone conferenceif we are serious then RP has to be reviewed. But who can review it and how long would it take. There are possibly only a limited number of people with the experience and skills for performing such a review. The last review took several person days (as far as I can remember). So the review process is possibly tied to some financial resource in order to sponsor the review. The problem is two-fold: 1. Identify the people who are able (and could be convinced) to do the review 2. Find the money to sponsor this work Is the Zope Foundation in any position to lead this process? Who else would be in a position to do so? My impression is that the second problem requires only organization. There are enough companies around in the market that still use Zope2 as their strategic platform. I'd expect some of them to be willing to pay for this investment. In a joined effort this should not be a huge amount for any individual company. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
On Wednesday 15 October 2008, Sidnei da Silva wrote: I don't want to rain on your parade, but I already did a first pass at reviewing the changes in Python 2.5 and Python 2.6. There are no significant changes that I could spot so far. Apparently the major changes are: I also did a review for Python 2.5 a while ago and all I could find were: * new missing builtins (zope.security) * A bug in the proxy code concerning correct slicing (zope.proxy, I think) I fixed both of these in the respective package. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Stephan Richter wrote: On Wednesday 15 October 2008, Sidnei da Silva wrote: I don't want to rain on your parade, but I already did a first pass at reviewing the changes in Python 2.5 and Python 2.6. There are no significant changes that I could spot so far. Apparently the major changes are: I also did a review for Python 2.5 a while ago... So does this mean RestrictedPython just had a bad emotional status in the community, but it is actually well proven and reviewed now? I always was under the impression that Jim feared the code and the required security audit was perceived as a major painful undertaking. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Hi there, On Wed, Oct 15, 2008 at 3:35 PM, Andreas Jung [EMAIL PROTECTED] wrote: [snip] If Python 2.6 is the latest official Python version of the 2.X line that there is a chance that this version will be supported by the Python community in the long term. So supporting Python 2.4 or Python 2.5 does not make much sense to me. RestrictedPython: I talked with Alan Runyan about this topic at the Plone conferenceif we are serious then RP has to be reviewed. But who can review it and how long would it take. There are possibly only a limited number of people with the experience and skills for performing such a review. The last review took several person days (as far as I can remember). So the review process is possibly tied to some financial resource in order to sponsor the review. Yes, I agree. How do we go about finding sponsors and people willing to do the review? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
On Wed, Oct 15, 2008 at 11:28 AM, Hanno Schlichting [EMAIL PROTECTED] wrote: Stephan Richter wrote: On Wednesday 15 October 2008, Sidnei da Silva wrote: I don't want to rain on your parade, but I already did a first pass at reviewing the changes in Python 2.5 and Python 2.6. There are no significant changes that I could spot so far. Apparently the major changes are: I also did a review for Python 2.5 a while ago... So does this mean RestrictedPython just had a bad emotional status in the community, but it is actually well proven and reviewed now? I always was under the impression that Jim feared the code and the required security audit was perceived as a major painful undertaking. That was my perception too. But after looking at the code it is really not bad at all. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Hanno Schlichting wrote: Stephan Richter wrote: On Wednesday 15 October 2008, Sidnei da Silva wrote: I don't want to rain on your parade, but I already did a first pass at reviewing the changes in Python 2.5 and Python 2.6. There are no significant changes that I could spot so far. Apparently the major changes are: I also did a review for Python 2.5 a while ago... So does this mean RestrictedPython just had a bad emotional status in the community, but it is actually well proven and reviewed now? It has been reviewed by Jim for Python 2.4. When he did this, he wrote notes.txt which gives you a quick overview over the internals. The GSoC-sponsored efforts to port Zope 3 and Zope 2 to Python 2.5 included a review of RestrictedPython as well. As far as I can tell, the only changes to RestrictedPython were made by Sidnei a couple of days ago when he fixed it up for the new keywords in Python 2.6 and added some tests for features new in Python 2.5 and 2.6. I always was under the impression that Jim feared the code and the required security audit was perceived as a major painful undertaking. It's certainly something that should be undertaken carefully. New syntactical features (such as the =+ operator in the past, or the 'with' statement or inplace 'if' now) have to be analyzed with respect to their bytecode. Bytecode changes have to be tracked as well. It looks like Sidnei is on top of that already, though, which is certainly great to hear! Go Sidnei! :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
On Oct 15, 2008, at 3:27 AM, Thomas Lotze wrote: There has been a problem with zope.interface's verifyObject function that occurs in conjunction with Python properties: when verifyObject checks for the presence of an object's attribute, it does so by using hasattr() which in turn tries a getattr() call. If the attribute is implemented as a property, this may raise an exception which will be masked by hasattr() due to a bare except: clause. One scenario where this is a problem is a property that performs some component lookup which will succeed at application runtime but not in unit tests where verifyObject is commonly used. While it has also been argued that behaviour so complex that it may raise an Exception should not be implemented as a property in the first place, we believe that verifyObject should handle this case better than it currently does. A possible fix would be to add an additional check for a data descriptor on the object's class if the hasattr() test returns False. Are there any objections against modifying verifyObject in this way? I would change it to just use getattr rather than hasattr. try: getattr(ob, name) except AttributeError: return False ... Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] traversal: different with and without a request
Hi, we stumbled over an annoyance that took a while to debug: Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test. In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not. We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent. Christian and Wolfgang -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ForbiddenAttribute: why subclass AttributeError?
Hi, Why is a ForbiddenAttribute also an AttributeError? Is this intended to avoid 'information leaks'? We found a nasty side-effect together with getattr and annotations: a user that didn't have read-access to __annotations__ would end up trying to create the annotations container again and again because getattr(obj '__annotations__', None) would return None instead of propagating the ForbiddenAttribute exception. Christian and Wolfgang -- Christian Theune · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
Christian Theune wrote: we stumbled over an annoyance that took a while to debug: Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test. In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not. We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent. zope.traversing is a mess. First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Jim Fulton [EMAIL PROTECTED] wrote: I would change it to just use getattr rather than hasattr. try: getattr(ob, name) except AttributeError: return False ... This doesn't handle the case that the attribute exists as a property but raises an AttributeError when trying to produce its value. Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
On 15.10.2008 14:44 Uhr, Martijn Faassen wrote: Hi there, On Wed, Oct 15, 2008 at 2:30 PM, Andreas Jung[EMAIL PROTECTED] wrote: If the latter, what about the security review for untrusted code? You mean the review of RestrictedPython? Yes. If RestrictedPython is to be reviewed for changes, it *might* be easier to do this for 2.4 - 2.5 instead of the big leap of two python versions. This depends a bit on how such a review is structured. If Python 2.6 is the latest official Python version of the 2.X line that there is a chance that this version will be supported by the Python community in the long term. So supporting Python 2.4 or Python 2.5 does not make much sense to me. RestrictedPython: I talked with Alan Runyan about this topic at the Plone conferenceif we are serious then RP has to be reviewed. But who can review it and how long would it take. There are possibly only a limited number of people with the experience and skills for performing such a review. The last review took several person days (as far as I can remember). So the review process is possibly tied to some financial resource in order to sponsor the review. Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:[EMAIL PROTECTED] title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote: Jim Fulton [EMAIL PROTECTED] wrote: I would change it to just use getattr rather than hasattr. try: getattr(ob, name) except AttributeError: return False ... This doesn't handle the case that the attribute exists as a property but raises an AttributeError when trying to produce its value. Yes, but this is still better than hasattr() which eats all exceptions. I think eating AttributeErrors is fine because to the user of 'ob', it would seem that ob.attr wouldn't exist anyway if it threw an AttributeError (even if that exception was about something else, it's still an AttributeError). I suggest doing marker = object() return getattr(ob, name, marker) is marker rather than return hasattr(ob, name) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Lotze wrote: Jim Fulton [EMAIL PROTECTED] wrote: I would change it to just use getattr rather than hasattr. try: getattr(ob, name) except AttributeError: return False ... This doesn't handle the case that the attribute exists as a property but raises an AttributeError when trying to produce its value. What is the difference? Any property which raises an attribute error is broken, and does not satisfy the contract of the interface: it might as well not be there at all. On a de gustibus note, I would have spelled it without the try: return getattr(ob, name, ob) is not ob Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI9hhp+gerLs4ltQ4RAvYYAJkBpvcecqFmmSf9c9KMtPITnocOgQCghD71 irczDNf47QMt2qXB6LuBPKw= =Atrg -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
On Wed, Oct 15, 2008 at 06:02:55PM +0200, Philipp von Weitershausen wrote: Christian Theune wrote: we stumbled over an annoyance that took a while to debug: Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test. In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not. We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent. zope.traversing is a mess. You can drop the .traversing bit and it'll still be true. On the other hand Perl is a mess, yet it is quite successful. First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. I've seen these two called object traversal and URL traversal respectively. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess? Marius Gedminas -- Please do not even think about automatically normalizing file names anywhere. There is absolutely no need for introducing such nonsense, and deviating from the POSIX requirement that filenames be opaque byte strings is a Bad Idea[TM] (also known as NTFS). -- Markus Kuhn signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
Philipp von Weitershausen wrote: First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess? This is very useful information that would have saved me a lot of confusion years ago. Is this written somewhere permanent, at least? Everyone who does anything at all with ITraversable or IPublishTraverse needs to understand this, at least until traversal is redesigned. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Sidnei da Silva wrote: On Tue, Oct 14, 2008 at 2:16 PM, Andreas Jung [EMAIL PROTECTED] wrote: Thanks for starting the discussion. Going for Python 2.6 also requires that we get the ZCA running on top of Python 2.6 until some time next year. FWIW, that's what I've been working on. There's enough of the the ZCA working on Python 2.6 to run Zope 2. Would anything else be needed? I would say we are pretty much done as far as Zope 2 is concerned. Concerning the component architecture or the entire port? If the latter, what about the security review for untrusted code? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Martijn Faassen wrote: On Wed, Oct 15, 2008 at 2:30 PM, Andreas Jung [EMAIL PROTECTED] wrote: You mean the review of RestrictedPython? Yes. If RestrictedPython is to be reviewed for changes, it *might* be easier to do this for 2.4 - 2.5 instead of the big leap of two python versions. This depends a bit on how such a review is structured. It should be easier to never officially support Python 2.5, though. We do want to end up at supporting Python 2.6 in the end. I doubt that the review work of Python 2.4 - 2.5 plus 2.5 - 2.6 is smaller than the Python 2.4 - 2.6 work. If it is easier doing this internally without having to support the intermediate result should still be less work. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Hi there, On Wed, Oct 15, 2008 at 2:30 PM, Andreas Jung [EMAIL PROTECTED] wrote: If the latter, what about the security review for untrusted code? You mean the review of RestrictedPython? Yes. If RestrictedPython is to be reviewed for changes, it *might* be easier to do this for 2.4 - 2.5 instead of the big leap of two python versions. This depends a bit on how such a review is structured. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] traversal: different with and without a request
El 15 Oct 2008, a las 19:24 , Shane Hathaway escribió: Philipp von Weitershausen wrote: First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of traversal are intermingled is when ++namespaces+ + are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess? This is very useful information that would have saved me a lot of confusion years ago. Is this written somewhere permanent, at least? Not that I know of. The documentation of zope.traversing would probably be a good place to put it. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12 - supported Python versions
Folks,
I don't want to rain on your parade, but I already did a first pass at
reviewing the changes in Python 2.5 and Python 2.6. There are no
significant changes that I could spot so far. Apparently the major
changes are:
- Ternary 'if'
- Context Managers ('with' keyword)
Both of those are just syntactic sugar for already existing idioms and
they are pretty much covered by already existing transformation of the
ast tree.
Also, the only new bytecode seems to be 'WITH_CLEANUP' which is part
of the handling of the 'with' keyword.
In general, RestrictedPython seems to be well-structured and the tests
are easy to extend and understand for someone that played with ast
(like the folks playing with z3c.pt).
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote at 2008-10-15 09:27 +0200: There has been a problem with zope.interface's verifyObject function that occurs in conjunction with Python properties: when verifyObject checks for the presence of an object's attribute, it does so by using hasattr() which in turn tries a getattr() call. If the attribute is implemented as a property, this may raise an exception which will be masked by hasattr() due to a bare except: clause. One scenario where this is a problem is a property that performs some component lookup which will succeed at application runtime but not in unit tests where verifyObject is commonly used. While it has also been argued that behaviour so complex that it may raise an Exception should not be implemented as a property in the first place, we believe that verifyObject should handle this case better than it currently does. A possible fix would be to add an additional check for a data descriptor on the object's class if the hasattr() test returns False. Are there any objections against modifying verifyObject in this way? I fear your must describe your proposed change more precisely: When your problem is the stated use case: verifyObject fails because something necessary for the interface to be properly implemented is missing in the test but available in a real environment, I would say: that is very fine: Do not change verifyObject but give the test instead the resources expected to be available in the real environment. When you want to provide a better (more informative) exception (not fails to implement but ComponentLookupError), then I am with you. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
