Re: [Zope-dev] Dependencies question
Previously Dan Korostelev wrote: I was looking at dependencies of various zope.* packages and see that some packages depend on other because of ZCML directives and some are not. For example: The zope.app.catalog package depends on zope.app.component, but doesn't use it anywhere in non-testing code, however it does use the ``class`` directive, registered in zope.app.component. While the zope.app.keyreference doesn't depend on zope.app.component at all, but uses ``class`` directive as well. So, the question is: what's the common policy for that? Should we depend on packages that is used in ZCML or not? Or maybe ZCML-related dependencies should be in some extras_require, say zcml? There is certainly precendence for that (zope.component and zope.i18n iirc). Personally, I think, that extras_require way is a nice compromise for that. Because many of packages can be used greatly without ZCML configuration, but getting ZCML-reqired dependencies should be easy. +1 Those zcml dependencies make it a lot more painful to use zope.* packages in other environments. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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.browser?
Hi, Am Freitag, den 12.12.2008, 05:06 +0100 schrieb Roger Ineichen: ... Let's keep this pending and discuss at a later time again. ok. please let me know when there's cleard space for features, regards, robert Regards Roger Ineichen ___ 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.browser?
On 2008-12-11 17:13:06 +0100, Roger Ineichen d...@projekt01.ch said: Hi Martijn Betreff: Re: [Zope-dev] zope.browser? Martijn Faassen wrote: Hi there, I saw that Roger Ineichen created and released a package called zope.browser. I assume that this package is intended to reduce dependencies, which is a project I applaud. So far I don't see any effect of this - in fact several packages now have an added dependency to zope.browser that wasn't there before. I'm sure there's a bit of the plan I don't understand yet - please enlighten me? Looking more, I've noticed that zc.sourcefactory replaces the dependency on zope.app.form with this package. That seems to be an improvement. Since I'm quite interested in this project, I'd like to hear much more about how we will determine which kind of dependency surgery we'll do next. I just moved the zope.app.form.interfaces.ITerms interface to this package. Which makes it possible to implement ISource and their widgets in z3c.form wihtout to depend on zope.app.browser. (zagy branch in z3c.form) That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] C-extension in zope.i18nmessageid
I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. \malthe ___ 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] C-extension in zope.i18nmessageid
Hi Malthe Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. IIRC, the C extension is needed to make messageids truly immutable. This guards against certain kinds of errors and also means they don't need to be security proxied, which probably gives a good speedup somewhere. +1 to documenting why this is a good idea. -1 on removing the extension. HTH - Jacob ___ 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] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 11:28:48AM +, Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. C extensions are usually optimizations. If there are no objections, I will merge this into trunk shortly. Could you please measure the impact on RAM usage and rendering speed of this removal for an app that uses Zope's i18n mechanism for rendering templates? Marius Gedminas -- The reason computer chips are so small is that computers don't eat much. 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] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 11:28, Malthe Borch mbo...@gmail.com wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. The C extension is required to make messageids immutable. Because they are immutable, the security machinery can treat them as rocks, e.g. safe to pass around. Removing the C-extension undoes this, as you cannot make truely immutable. See the original proposal: http://wiki.zope.org/zope3/TurningMessageIDsIntoRocks I'm sure Phillip and Jim can clarify the security implications of undoing this work. -- Martijn Pieters ___ 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] C-extension in zope.i18nmessageid
Martijn Pieters wrote: The C extension is required to make messageids immutable. Because they are immutable, the security machinery can treat them as rocks, e.g. safe to pass around. Removing the C-extension undoes this, as you cannot make truely immutable. I believe it is possible to do this in pure Python: We'll set up a security-proxied global dictionary ``messages`` that maps object_id of message - weakref(message) Then, the ``Message`` class would roughly look like this: class Message(unicode): def __new__(...): self = unicode.__new__(...) messages = removeSecurityProxy(messages) messages[id(self)] = (default, domain, mapping) @property def default(self): return messages[id(self)][0] The message data is effectively immutable, since the ``messages`` dictionary is security-proxied. To make sure the message properties are persisted along with the message, we must override the __reduce__-method to maintain the ``messages`` dict upon load. \malthe ___ 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: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Thu Dec 11 12:00:00 2008 UTC to Fri Dec 12 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Thu Dec 11 20:33:39 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010637.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Thu Dec 11 20:35:09 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010638.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Thu Dec 11 20:27:38 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010633.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Thu Dec 11 20:29:09 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010634.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Thu Dec 11 20:30:39 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010635.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Thu Dec 11 20:32:09 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010636.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.browser?
Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their 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.browser?
On Fri, Dec 12, 2008 at 02:24:09PM +0100, Martijn Faassen wrote: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? One issue is that it's impossible to write code that's deprecation warning free and works across multiple versions of dependencies. That forces people to become accustomed to seeing and ignoring deprecation warnings. 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 ) -- Brian Sutherland ___ 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] z3c.form bug with radio widget label
hey, i guess i found a bug in z3c.form.browser.radio. in z3c.form.browser.radio, line 49 (class RadioWidget, def update), the line should read label = term.value instead of label = term.token we found this, while trying to display some unicode characters (umlaute) in radio widget labels. this issue is still valid in current trunk (file revision 78513). i report it here, because i could not find a bug tracker for z3c.form. is there any? cheers, hannes ___ 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.browser?
On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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.browser?
Hi, Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick: On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) regards, robert ___ 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] C-extension in zope.i18nmessageid
Malthe Borch wrote: I believe it is possible to do this in pure Python: The implementation may reviewed in this branch: http://svn.zope.org/zope.i18nmessageid/branches/c-extension-less/ \malthe ___ 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] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 12:45:27PM +, Malthe Borch wrote: Martijn Pieters wrote: The C extension is required to make messageids immutable. Because they are immutable, the security machinery can treat them as rocks, e.g. safe to pass around. Removing the C-extension undoes this, as you cannot make truely immutable. I believe it is possible to do this in pure Python: I have doubts about that, but I don't think I'm smart enough to consider all the security implications. We'll set up a security-proxied global dictionary ``messages`` that maps object_id of message - weakref(message) Then, the ``Message`` class would roughly look like this: class Message(unicode): def __new__(...): self = unicode.__new__(...) messages = removeSecurityProxy(messages) messages[id(self)] = (default, domain, mapping) Careful: id(some_object) will likely be reused when the old object is garbage collected. @property def default(self): return messages[id(self)][0] The message data is effectively immutable, since the ``messages`` dictionary is security-proxied. To make sure the message properties are persisted along with the message, we must override the __reduce__-method to maintain the ``messages`` dict upon load. -- http://pov.lt/ -- Zope 3 consulting and development 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] z3c.form bug with radio widget label
On Fri, Dec 12, 2008 at 02:33:53PM +, Johannes Raggam wrote: hey, i guess i found a bug in z3c.form.browser.radio. in z3c.form.browser.radio, line 49 (class RadioWidget, def update), the line should read label = term.value You can't assume ``value`` will be a string. People routinely use all sorts of objects there. instead of label = term.token we found this, while trying to display some unicode characters (umlaute) in radio widget labels. You should really be explicitly specifying the titles for your terms. this issue is still valid in current trunk (file revision 78513). i report it here, because i could not find a bug tracker for z3c.form. is there any? https://bugs.launchpad.net/zope3 (Since https://bugs.launchpad.net/z3c.form doesn't exist.) -- http://pov.lt/ -- Zope 3 consulting and development 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] C-extension in zope.i18nmessageid
Marius Gedminas wrote: Careful: id(some_object) will likely be reused when the old object is garbage collected. This has been worked around using the weak reference dictionary. \malthe ___ 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] C-extension in zope.i18nmessageid
On Dec 12, 2008, at 6:28 AM, Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. I object. Please drop it. 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 )
Re: [Zope-dev] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 17:01, Jim Fulton j...@zope.com wrote: On Dec 12, 2008, at 6:28 AM, Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. I object. Please drop it. I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. -- Martijn Pieters ___ 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] C-extension in zope.i18nmessageid
Martijn Pieters wrote: I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. The obvious motivation for this is to: * Reduce code complexity * Allow operation in a pure-Python environment As for cons, any change is a risk and I believe the concensus seen in this thread is that it outweighs the above mentioned motivation. \malthe ___ 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] Dependencies question
On Friday 12 December 2008, Wichert Akkerman wrote: Personally, I think, that extras_require way is a nice compromise for that. Because many of packages can be used greatly without ZCML configuration, but getting ZCML-reqired dependencies should be easy. +1 Those zcml dependencies make it a lot more painful to use zope.* packages in other environments. +1 from me as well. 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] C-extension in zope.i18nmessageid
Malthe Borch wrote: Martijn Pieters wrote: I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. The obvious motivation for this is to: * Reduce code complexity * Allow operation in a pure-Python environment As for cons, any change is a risk and I believe the concensus seen in this thread is that it outweighs the above mentioned motivation. Allowing operation in a pure-Python environment is a worthwhile goal, which I support. Unless it can be clearly demonstrated that the new method is equivalent in both performance and security, talk of dropping the C extension seems somewhat premature. A pure Python fallback for this module would however be interesting to everybody, I think. My suspicion from observing the discussions in this thread so far indicate that a drop in code complexity doesn't seem to be a necessary consequence of rewriting to Python either. Regarsd, 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] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 18:51, Martijn Faassen faas...@startifact.com wrote: Unless it can be clearly demonstrated that the new method is equivalent in both performance and security, talk of dropping the C extension seems somewhat premature. A pure Python fallback for this module would however be interesting to everybody, I think. There is one already. However, it isn't immutable and thus a security risk. -- Martijn Pieters ___ 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] C-extension in zope.i18nmessageid
Martijn Faassen wrote: My suspicion from observing the discussions in this thread so far indicate that a drop in code complexity doesn't seem to be a necessary consequence of rewriting to Python either. The proposed implementation has already been implemented (walk up this thread); it is indeed much less complex. \malthe ___ 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] C-extension in zope.i18nmessageid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Malthe Borch wrote: Martijn Pieters wrote: I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. The obvious motivation for this is to: * Reduce code complexity * Allow operation in a pure-Python environment As for cons, any change is a risk and I believe the concensus seen in this thread is that it outweighs the above mentioned motivation. Allowing operation in a pure-Python environment is a worthwhile goal, which I support. Unless it can be clearly demonstrated that the new method is equivalent in both performance and security, talk of dropping the C extension seems somewhat premature. A pure Python fallback for this module would however be interesting to everybody, I think. My suspicion from observing the discussions in this thread so far indicate that a drop in code complexity doesn't seem to be a necessary consequence of rewriting to Python either. I question the *actual* security benefits of making the message IDs truly read-only: I think the real intent is to avoid a common class of programming error, rather than to keep Black Hats out. For that side of the problem, we could use read-only properties for the data, and used something like the '__' prefix for the real backing-store attributes, then only folks who were being silly would ever change them. This is Python, after all: we're all grownups should apply. I'm willing to be shown wrong, of course, but I want to see a non-hypothetical attack vector which doesn't involve running trusted code from the filesystem. ;) (smiley because what other kind of code do we have in Z3 applications, anyway?) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com 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 iD8DBQFJQtrc+gerLs4ltQ4RAh6zAKC11lXsLS4aiLEmi97Bst5TXjemOQCeMx3R J4N59zGMJ4+hGY+bq4i8nEY= =Rplt -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 )
[Zope-dev] adapting to None
Hi All, I have a need to be able to adapting certain objects to None, eg: def some_adapter(obj): if something: return None return somethingelse This is tricky, since returning None from an adapter results in a TypeError. I eventually came up with the idea of having a subclass of Interface do what I needed: empty = object() class IFieldType(Interface): def __call__(self,*args,**kw): r = Interface.__call__(*args,**kw) if r is empty: return None return r I suspect this would work with the python implementation of Interface, but it certainly doesn't with the C implementation. What am I doing wrong and how can I achieve what I'm after? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Fwd: Help with RelStorage ...
Hi, I'm having a bit of a problem that looks like a 32 bit vs 64 bit issue with RelStorage, can anyone help? If I do a clean install of RelStorage and ZODB on a 32 bit Ubuntu system, I get one error when I run the tests as follows; == FAIL: checkPackWithMultiDatabaseReferences (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-i686.egg/ZODB/tests/PackableStorage.py”, line 329, in checkPackWithMultiDatabaseReferences assert(len(self._storage) == 1) AssertionError ———- I'm not convinced this in itself is a problem. However, when I do the same on a 64 bit system I get additional errors as follows; == ERROR: checkPackUnlinkedFromRoot (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/PackableStorage.py”, line 558, in checkPackUnlinkedFromRoot tid = log[0]['id'] IndexError: list index out of range == ERROR: checkTransactionalUndoAfterPackWithObjectUnlinkFromRoot (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/TransactionalUndoStorage.py”, line 506, in checkTransactionalUndoAfterPackWithObjectUnlinkFromRoot tid = log[0]['id'] IndexError: list index out of range == FAIL: checkLoadBefore (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/RevisionStorage.py”, line 62, in checkLoadBefore assert prev middle cur # else the snooze() trick failed AssertionError == FAIL: checkPackUndoLog (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/PackableStorage.py”, line 629, in checkPackUndoLog self.assertEqual(1,len(self._storage.undoLog())) AssertionError: 1 != 0 == FAIL: checkPackWithMultiDatabaseReferences (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/PackableStorage.py”, line 329, in checkPackWithMultiDatabaseReferences assert(len(self._storage) == 1) AssertionError == FAIL: checkTransactionalUndoAfterPack (__main__.MySQLTests) ———- Traceback (most recent call last): File “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/TransactionalUndoStorage.py”, line 452, in checkTransactionalUndoAfterPack eq(len(info2), 2) AssertionError: 0 != 2 ———- I have tried; System Python @ 2.5 and Plone Python @ 2.4.5 easy_install RelStorage and SVN RelStorage ZODB 3.8.0 and ZODB 3.8.1 All essentially give the same results. [I've tried ZODB 3.9, but you really don't want to see that one.] Can anyone point me in the right direction / suggest something else to try ??? tia Gareth. ___ 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 )
