[Zope-dev] RFC: product initialization cleanup and improvements
Hi! Working on the five:registerClass directive for Five 1.2 and Zope 2.9 I had a closer look at the product initialization code. I propose the following modifications for the dicts in Products.meta_types (set by registerClass): 1.) 'action' key: - I'd like to give empty 'action' values a special meaning: The meta_type is not visible in the add drop down in the ZMI. The five:registerClass directive allows to set empty 'action' values. This would resolve http://www.zope.org/Collectors/Zope/1885 . Filtering out meta_types with empty 'action' values is a two line change in main.dtml. I'd like to make that change also on the 2.8 branch to enable that feature for 2.8.5 with Five 1.2. 2.) 'interfaces' key: - Does currently only contain oldstyle interfaces. The code in OFS.ObjectManager that uses that key works also with z3 interfaces. I'd like to add z3 interfaces to the value of that key. That would e.g. allow to set only new style interfaces on catalog index classes. 3.) 'product' key: -- AFAICS it isn't used in Zope itself. I'd like to add a note that it might be removed in a future version. 4.) related cleanup: Application.install_product has some backwards compatibility code for products that have initialization code outside the 'initialize' method of their __init__.py. This is deprecated at least for 5 years. I'd like to add explicit deprecation warnings on the 2.8 branch and to remove that code for Zope 2.9. This isn't much work, it can all be done in time for the Zope 2.9 beta. Any feedback is welcome. If there are no objections, I'll make the changes as proposed. Cheers, Yuppie ___ 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] Re: New testrunner on the Zope 2 trunk.
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Weird. I can't reproduce this. Is anyone else seeing this? For the benefit of those playing along at home: Jim and I discovered this evening that we were running on mostly-identical platforms (Ubuntu Breezy 5.10, Python 2.3.5 compiled from source). The only difference we could find was that I had rebuilt my Pythnon using GCC 4.0, while Jim's was one built under GCC 3.3. Go figure, Sigh. I rebuilt Python 2.3.5: [EMAIL PROTECTED]:~/p/z2/2$ /usr/local/python/2.3.5b/bin/python Python 2.3.5 (#1, Oct 27 2005, 10:22:20) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2 Type help, copyright, credits or license for more information. I don't get a test failure with this Python: cd ~/p/z2/2/ /usr/local/python/2.3.5b/bin/python test.py -szope.testing Running tests at level 1 Running unit tests: Running: .. ... Ran 89 tests with 0 failures and 0 errors in 32.003 seconds. Compilation finished at Thu Oct 27 11:04:40 Is anyone else getting this test failure? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Re: RFC: product initialization cleanup and improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Working on the five:registerClass directive for Five 1.2 and Zope 2.9 I had a closer look at the product initialization code. I propose the following modifications for the dicts in Products.meta_types (set by registerClass): 1.) 'action' key: - I'd like to give empty 'action' values a special meaning: The meta_type is not visible in the add drop down in the ZMI. The five:registerClass directive allows to set empty 'action' values. This would resolve http://www.zope.org/Collectors/Zope/1885 . Filtering out meta_types with empty 'action' values is a two line change in main.dtml. I'd like to make that change also on the 2.8 branch to enable that feature for 2.8.5 with Five 1.2. +1. 2.) 'interfaces' key: - Does currently only contain oldstyle interfaces. The code in OFS.ObjectManager that uses that key works also with z3 interfaces. I'd like to add z3 interfaces to the value of that key. That would e.g. allow to set only new style interfaces on catalog index classes. I'd just as soon rip old-style interfaces out by the roots. +1 for allowing new-style ones in 2.8.x; -1 for continuing to support old-style ones on the trunk (anybody clever enough to use the old ones back in the day is clever enough, and should be motivated enough, to convert). 3.) 'product' key: -- AFAICS it isn't used in Zope itself. I'd like to add a note that it might be removed in a future version. +1. 4.) related cleanup: Application.install_product has some backwards compatibility code for products that have initialization code outside the 'initialize' method of their __init__.py. This is deprecated at least for 5 years. I'd like to add explicit deprecation warnings on the 2.8 branch and to remove that code for Zope 2.9. +1. This isn't much work, it can all be done in time for the Zope 2.9 beta. Any feedback is welcome. If there are no objections, I'll make the changes as proposed. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYPhi+gerLs4ltQ4RAjqAAKCa3BqERqXAC/uYPQp5n9Y8ZZL33QCeJ65o rKUDm17Qy3x+iNa1+5HxYnU= =e0ZF -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] Re: New testrunner on the Zope 2 trunk.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Sigh. I rebuilt Python 2.3.5: [EMAIL PROTECTED]:~/p/z2/2$ /usr/local/python/2.3.5b/bin/python Python 2.3.5 (#1, Oct 27 2005, 10:22:20) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)] on linux2 Type help, copyright, credits or license for more information. I don't get a test failure with this Python: cd ~/p/z2/2/ /usr/local/python/2.3.5b/bin/python test.py -szope.testing Running tests at level 1 Running unit tests: Running: .. ... Ran 89 tests with 0 failures and 0 errors in 32.003 seconds. Compilation finished at Thu Oct 27 11:04:40 Is anyone else getting this test failure? Just to note that the tests aren't running cleanly on Stefan Holek's box, either (but they fail differently): http://mail.zope.org/pipermail/zope-tests/2005-October/003421.html http://mail.zope.org/pipermail/zope-tests/2005-October/003422.html Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYPj0+gerLs4ltQ4RAv6bAJ4jZvj3unZ2mupaMKFVK0886+iuvgCgvi3I ka6+lOBnQ9l34slY+oD7kR8= =b/x2 -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] Re: New testrunner on the Zope 2 trunk.
Tres Seaver wrote: ... Just to note that the tests aren't running cleanly on Stefan Holek's box, either (but they fail differently): http://mail.zope.org/pipermail/zope-tests/2005-October/003421.html http://mail.zope.org/pipermail/zope-tests/2005-October/003422.html These are not failures. They are also not complete output. I'm hoping that Stefan will look at this. We also plan to add zope 2 to the buildbot config. It would be nice is someone would address the deprecation warning by getting rid of the whrandom reference. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Removing whrandom in Zope 2.9 (was Re: New testrunner on the Zope 2 trunk.)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Tres Seaver wrote:
...
Just to note that the tests aren't running cleanly on Stefan Holek's
box, either (but they fail differently):
http://mail.zope.org/pipermail/zope-tests/2005-October/003421.html
http://mail.zope.org/pipermail/zope-tests/2005-October/003422.html
These are not failures. They are also not complete output.
I'm hoping that Stefan will look at this.
We also plan to add zope 2 to the buildbot config.
It would be nice is someone would address the deprecation
warning by getting rid of the whrandom reference. :)
Jim
FWIW:
$ pwd
/home/tseaver/projects/Zope-CVS/Zope-2_8-branch
$ find . -name *.py | grep -v build-base | xargs grep -l whrandom
./lib/python/AccessControl/DTML.py
./lib/python/Products/PythonScripts/help/PythonScript.py
./lib/python/Products/ZCatalog/regressiontests/regressionCatalog.py
./lib/python/Products/ZCatalog/regressiontests/loadmail.py
./lib/python/RestrictedPython/Utilities.py
./lib/python/DocumentTemplate/DT_Util.py
./lib/python/zope/security/examples/sandbox.py
./lib/python/zope/security/examples/sandbox_security.py
The 'regressiontest' cases have been ripped out on the trunk already.
For 2.8, we can't rip out the 'AccessControl/DTML.py' version without
breaking third-party code which uses it in DTML. Here is what it does:
import SecurityManagement, string, math, whrandom, random
...
whrandom.__allow_access_to_unprotected_subobjects__=1
random.__allow_access_to_unprotected_subobjects__=1
Likewise RestrictedPython/Utilities.py:
import string, math, random, whrandom
...
utility_builtins = {}
...
utility_builtins['random'] = random
utility_builtins['whrandom'] = whrandom
The Zope3 stuff could likely be replaced (e.g. for a 3.0.2 release), and
should be gone for 2.9 / 3.2.
Hmm, I see that RestrictedPython/Utilities.py on the Z3 trunk aliases
'random' as 'whrandom' -- could we use that strategy for 2.8 etc.?
We could remove them for 2.9, I guess, and just make people fix their
applications.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDYRtT+gerLs4ltQ4RAtvdAKDMKwFPaRysMkNa6c/k1f70YkWYNgCfRvcu
xqLrTdDlDHrY41PhmyFPIiI=
=zd+o
-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] Re: Removing whrandom in Zope 2.9 (was Re: New testrunner on the Zope 2 trunk.)
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- FWIW: Alot. :) $ pwd /home/tseaver/projects/Zope-CVS/Zope-2_8-branch $ find . -name *.py | grep -v build-base | xargs grep -l whrandom ./lib/python/AccessControl/DTML.py ./lib/python/Products/PythonScripts/help/PythonScript.py ./lib/python/Products/ZCatalog/regressiontests/regressionCatalog.py ./lib/python/Products/ZCatalog/regressiontests/loadmail.py ./lib/python/RestrictedPython/Utilities.py ./lib/python/DocumentTemplate/DT_Util.py ./lib/python/zope/security/examples/sandbox.py ./lib/python/zope/security/examples/sandbox_security.py Sigh. ... Hmm, I see that RestrictedPython/Utilities.py on the Z3 trunk aliases 'random' as 'whrandom' -- could we use that strategy for 2.8 etc.? Yes. random has the same documented functions and signatures as whrandon. We could remove them for 2.9, I guess, and just make people fix their applications. I suggest we make aliases and generate deprecation warnings if whrandom is used. (The later may be tricky, I realize.) Maybe for now, just make aliases and move on. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Experiencing TypeError: The object is not a PySECURITY_ATTRIBUTES object
The bad news is that I don't think I'll ever put in enough time to fully understand what went wrong here. The good news is that the newly-released Zope 2.8.4 Windows installer, at http://www.zope.org/Products/Zope/2.8.4 includes pywin32 build 205. If that doesn't fix PySECURITY_ATTRIBUTES problems for Plone users, you know which Mark Hammond to contact ;-) Thanks to all for the help! ___ 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] Re: RFC: product initialization cleanup and improvements
Hi Tres! Tres Seaver wrote: yuppie wrote: 1.) 'action' key: - I'd like to give empty 'action' values a special meaning: The meta_type is not visible in the add drop down in the ZMI. The five:registerClass directive allows to set empty 'action' values. This would resolve http://www.zope.org/Collectors/Zope/1885 . Filtering out meta_types with empty 'action' values is a two line change in main.dtml. I'd like to make that change also on the 2.8 branch to enable that feature for 2.8.5 with Five 1.2. +1. Ouch! I thought everything is in place for that feature, but an important piece of the puzzle is missing: The fix for checkPermission. http://www.zope.org/Collectors/Zope/1774 _verifyObjectPaste uses a hack to work around that checkPermission issue, making 'action' required. Tres: You did have a look at issue #1774 a while ago. What do you think: How much work would it be to resolve this issue? I'm not a C programmer so I can't do it myself... 2.) 'interfaces' key: - Does currently only contain oldstyle interfaces. The code in OFS.ObjectManager that uses that key works also with z3 interfaces. I'd like to add z3 interfaces to the value of that key. That would e.g. allow to set only new style interfaces on catalog index classes. I'd just as soon rip old-style interfaces out by the roots. +1 for allowing new-style ones in 2.8.x; -1 for continuing to support old-style ones on the trunk (anybody clever enough to use the old ones back in the day is clever enough, and should be motivated enough, to convert). My goal is to make it possible to run products on Zope 2.9 without implementing any old-style interfaces. I think that's doable. But I can't see a need to break all products that use old-style interfaces. Cheers, Yuppie ___ 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] Mountpoints
FWIW, I know a couple of people are depending on this, so here's an update. I am working on merging multidatabase support, but I'm having some merge/update troubles (if you're interested in the symptoms, see http://www.plope.com/Members/chrism/heres_to_cvs). I suspect I'll work it out, but I've got my nose in Subversion documentation at the moment. On Oct 27, 2005, at 1:09 AM, Chris McDonough wrote: I lied. Due to completely preventable circumstances, this merge won't be done tonight; instead, it will be done tomorrow evening. - C On Mon, 2005-10-24 at 16:41 -0400, Tim Peters wrote: [Chris McDonough] Thanks for this! Not required, so long as I get to thank you for finishing it ;-) Looks like that test failure is incidental and not symptomatic of changes made to ZODB. I think Tres may have said that it can be fixed by merging in a fix from the Five HEAD, but I don't know this for fact first-hand. I'm sure that failure will go away by itself when you're working on the trunk instead of the branch. What I'd do now: - Check out Zope trunk. - Merge the branch into your trunk sandbox, and forget the branch. - Fix merge conflicts. I got one, in datatypes.py, and I didn't know immediately what to do about it so stopped there. You'll have better luck ;-). Note that, under SVN, after you fix a conflict, you have to do svn resolved path/to/conflicted/file; that's a gimmick to make sure you don't forget about conflicts. - svn up to make sure you've got all the externals the merged files point at. - svn up from time to time thereafter, to suck in other trunk changes as they get made. - Check it in when it's stable. - If it takes longer than expected, make a _new_ branch _from_ your merged-into-trunk local trunk sandbox. (That's easy: make a branch directory, svn switch to it from your local merged trunk sandbox, and svn commit -- all done). It's encouraging that most of the tests pass but there are a paucity of tests that specifically test Zope 2 multidatabase-based mount points. There are a few convincing-looking decoys in Products.ZODBMountPoint.tests but I think I'll need to create a few more to get the warm and fuzzies before doing the merge. As above, you can do a _local_ merge right away. This would save you from other decoys (like the DeprecationWarnings that would no longer exist if you were using the trunk instead of the brach, and the failing-on-branch-but-not-trunk Five test). I recall that, historically, the Zope tests never failed when Zope mounting was in fact broken, so a fat +1 to beefing test coverage there. I have this on my plate for Wednesday evening. Understood; there really isn't any good TV on Wednesdays anymore ;-) ___ 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] Mountpoints
[Tim, trying to comfort a suffering Chris] ... End of story. Unless you feel you need to make another branch. In that case, still do the two steps above first. Then create a new branch from Zope trunk, svn switch your merged sandbox to that new branch, then svn checkin. That last part should have said svn commit. If it had, you'd already be done ;-) ___ 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] Mountpoints
Jim redid the way Zope trunk stitches in Zope3 since you last looked at this, and that can create some mechanical problems (of the kinds you're seeing, in fact). The svn docs probably won't help. Suggestion (which is repetition of what I suggested before this happened, but we'll gracefully let that pass ;-)): Check out a fresh, new copy of Zope trunk. Merge your branch into that. Thank you! Eagds. I *thought* I had done just that. I had even printed out your previous handholding email about this before starting. But no. I did not. Instead, to my horror, I realized had *copied* a trunk working copy (of an unknown vintage, although up-to-date according to svn status after an svn up) and then I'd merged the branch into that. So about a minute ago, I followed your instructions literally, figuring that I'd be able to sheepishly move on afterwards, but unfortunately it comes out the same. Literally, here are the commands: $ svn co svn+ssh://svn.zope.org/repos/main/Zope/trunk $ cd trunk $ svn merge -r 38624:HEAD svn+ssh://svn.zope.org/repos/main/Zope/ branches/zodb-blobs-branch $ svn up ... which comes out with Fetching external item into 'lib/python/zope/thread' External at revision 39684. Fetching external item into 'doc/ZEO' A doc/ZEO/cache.txt A doc/ZEO/ZopeREADME.txt A doc/ZEO/README.txt A doc/ZEO/trace.txt A doc/ZEO/howto.txt Updated external to revision 39684. Fetching external item into 'lib/python/zope' svn: Working copy 'lib/python/zope' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) I am reasonably confident that drinking just one more Yuengling will solve this problem in one way or another. - C ___ 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] Mountpoints
[Chris McDonough] FWIW, I know a couple of people are depending on this, so here's an update. I am working on merging multidatabase support, but I'm having some merge/update troubles (if you're interested in the symptoms, see http://www.plope.com/Members/chrism/heres_to_cvs). I suspect I'll work it out, but I've got my nose in Subversion documentation at the moment. Jim redid the way Zope trunk stitches in Zope3 since you last looked at this, and that can create some mechanical problems (of the kinds you're seeing, in fact). The svn docs probably won't help. Suggestion (which is repetition of what I suggested before this happened, but we'll gracefully let that pass ;-)): Check out a fresh, new copy of Zope trunk. Merge your branch into that. End of story. Unless you feel you need to make another branch. In that case, still do the two steps above first. Then create a new branch from Zope trunk, svn switch your merged sandbox to that new branch, then svn checkin. This way you shouldn't have any of the problems you've been seeing. If you do, double your money back ;-) ___ 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 )
