December 2008 - Zope-Dev

Next Step to Bug Resolution???
by Tim Cook 18 Jan '09

18 Jan '09

Hi All, I have had an issue on the table for months. I started a dialog about it here: http://mail.zope.org/pipermail/zope3-users/2008-October/008215.html The thread was interesting, helpful and did lead me to find an error in some schema definitions because of a misunderstanding of the required attribute. But that had nothing to do with the problem. It was first thought that it was a nasty, empty error report. After some investigation I discovered that it was an error that shouldn't be an error. Once I determined what I thought was the cause and a possible fix I posted a bug report on Launchpad https://bugs.launchpad.net/zope3/+bug/301226 So here we are. I have a possible solution and the only comments I get from the Zope Community are private emails (yes plural) asking me if anyone is working on this issue. I have to say that as far as I can tell; no. At this point I would be happier if someone just told me why my fix might negatively affect the other schema field validations. Now I realize that I must be the only person in the entire world to exercise zope.schema this way. BUT! It should work or it should be WELL documented that you cannot have cascading attribute=Object(IMySchema) definitions. The description of the project is here: http://www.openehr.org/wiki/display/dev/OSHIP+Developer%27s+Wiki This is a rather major project. See: http://www.ohloh.net/p/oship for some metrics. We have just received three years of funding from the Brazilian government to complete the platform and develop an Epidemiological decision support system on top of it to improve the recognition of syndromic outbreaks. Right now the hardworking core open source team understands that we need to replace zope.schema._field.py with our own to make it work. But when the project is ready, in a few months, for healthcare application developers worldwide to start using it. It may be a hard sell to say; "Yeah we use the really cool, robust, well tested and trusted application server called the Zope Component Architecture because it really shows the strengths of the open source development process. Oh, by the way, after everything is installed you have to replace a core ZCA file with the one we provide you in order to make it actually work." Doesn't sound very professional to me and it should be embarrassing to the Zope Community if that has to happen. Thank you for reading this long posting. I hope someone delivers me a Holiday package in the form of a fixed zope.schema package. :-) Cheers, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **************************************************************

8 27

zope.browser?
by Martijn Faassen 09 Jan '09

09 Jan '09

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? Regards, Martijn

12 46

adapting to None
by Chris Withers 09 Jan '09

09 Jan '09

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

5 13

bug in zope.testing 3.7.1?
by Chris Withers 09 Jan '09

09 Jan '09

Hi Guys, Line 396 of doctest.py contains code which is, at best, platform-specific (and so a bug) or, more likely, irrelevent. I have the following code that runs the tests in all my package's docs: def test_suite(): suite = unittest.TestSuite() for path in \ glob(os.path.join(os.path.dirname(__file__),'..','docs','*.txt')): suite.addTest( DocFileSuite(path, optionflags=REPORT_NDIFF|ELLIPSIS) ) return suite ...which runs fine on Windows (which makes me think that whole ValueError raise is bogus) and yet fails on Linux. Does anyone know why that raise is there? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 3

Sorting for zope.index
by Dan Korostelev 06 Jan '09

06 Jan '09

Hello, fellow zope developers :) I made a "nadako-sorting" branch of zope.index to add sorting support for zope indexes. I defined a new IIndexSort interface that specifies a "sort" method that takes document ids and returns an iterable of those ids, sorted by indexed value. It supports optional "limit" and "reverse" arguments. It also raises KeyError if you pass a docid that is not indexed by this index. Can someone review the interface definition and make any suggestions/objections? I also made an implementation for the FieldIndex that may not be too optimal, but I'm currently most interested in clean and universal IIndexSort definition that any index could efficiently implement. If there's no objections, I'd like to merge it to trunk and start adding sorting features for zope.app.catalog/z3c.indexer, as well as zc.catalog indexes. Thanks in advance! -- WBR, Dan Korostelev

3 8

Zope Tests: 4 OK, 2 Failed
by Zope Tests Summarizer 31 Dec '08

31 Dec '08

Summary of messages to the zope-tests list. Period Tue Dec 30 12:00:00 2008 UTC to Wed Dec 31 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 30 20:34:44 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010751.html Subject: FAILED (failures=1) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Tue Dec 30 20:36:14 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010752.html Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Tue Dec 30 20:28:44 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010747.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 30 20:30:14 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010748.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 30 20:31:44 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010749.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Tue Dec 30 20:33:14 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010750.html

1 0

Sorting for zope.app.catalog
by Dan Korostelev 30 Dec '08

30 Dec '08

Hello! After some discussion, sorting support for zope.index was added. It's now in zope.index 3.5.0. So, the next step is to add sorting/limiting/reversing to zope.app.catalog. I made a "nadako-sorting" branch of zope.app.catalog. It modifies the ``searchResults`` method of the catalog so it makes use of special keyword arguments, passed to it (i believe that's just like zope 2 catalog works). The names are: * _sort_index - the name of index to sort with * _reverse - reverse results * _limit - limit result set I added an underscore to the names to mark them as something special, not just index names and to avoid conflicting with index names that applications might use. I think there's no application on earth that has indexes with the names above, so that's not a problem. If _sort_index is not specified, catalog just uses list mechanisms to limit/reverse results. I don't think that makes any sense though. If _sort_index is specified, all sorting, reversing and limiting functionality is done by the ``sort`` method of specified index. That index should provide the new IIndexSort interface, defined by zope.index. I would like to merge that code to zope.app.catalog trunk and make a new feature release, containing this functionality. So I'd like community to review these changes and comment/object it. Thanks! -- WBR, Dan Korostelev

2 1

Zope Tests: 4 OK, 2 Failed
by Zope Tests Summarizer 30 Dec '08

30 Dec '08

Summary of messages to the zope-tests list. Period Mon Dec 29 12:00:00 2008 UTC to Tue Dec 30 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 29 20:36:56 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010745.html Subject: FAILED (failures=1) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Mon Dec 29 20:38:27 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010746.html Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Mon Dec 29 20:30:55 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010741.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 29 20:32:26 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010742.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 29 20:33:56 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010743.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Mon Dec 29 20:35:26 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010744.html

1 0

Proposal: Eliminating Globals as an import façade
by Tres Seaver 29 Dec '08

29 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have just checked in work on a separate branch which removes all use of 'Globals' as an indirection for imports within the Zope2 core, restoring the module to its original purpose, which was to hold shared data (e.g., the opened database, etc.). My rationale was that the current usage leads to a confusion of the actual dependencies, as well as oddball anti-patterns based around import cycles, etc. I got started on the task while trying to track down whatever import-time side effect it is which causes the current functional test failures on the trunk. I didn't actually *find* that issue, of course ;(, but I did get back to the staus quo ante. I am more comfortable now that finding those side-effects will be possible. I do restore the importable names in the module for benefit of 3rd party code, but that happens only at Zope2 startup time (for now). I would prefer that folks change that code, but want to leave such products workable indefinitely: at the moment, for instance, the CMF produccts work at appserver startup, although their tests fail (because the BBB is added too late). The branch is here: svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-no_globals_imports I would like to merge the branch soon, because it touches lots of files and is likely to hit conflicts if I let it go too long. I am still pondering whether to have the BBB imports done earlier: I really don't want to spew warnings about them, which is why I didn't use the "deferred import" mechanism initially. Thoughts? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJVmF++gerLs4ltQ4RAlWXAKCi4QDmGsXNG0mVz09DUpCGF2Z9rQCgkcKc 8z9rLwRRaKljOGyXiQTbYdg= =0oTI -----END PGP SIGNATURE-----

3 4

Zope Tests: 4 OK, 2 Failed
by Zope Tests Summarizer 29 Dec '08

29 Dec '08

Summary of messages to the zope-tests list. Period Sun Dec 28 12:00:00 2008 UTC to Mon Dec 29 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 28 20:36:55 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010739.html Subject: FAILED (failures=1) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sun Dec 28 20:38:25 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010740.html Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sun Dec 28 20:30:51 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010735.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 28 20:32:22 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010736.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 28 20:33:54 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010737.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 28 20:35:25 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010738.html

1 0