August 2008 - Zope-Dev

zope.testing 3.6.0 released
by Benji York 22 Oct '08

22 Oct '08

3.6.0 of zope.testing is out with my subprocess parallelization branch merged (plus I fixed a few bugs in the trunk). There were several other changes, here's the pertinent part of the release notes: - Added -j option to parallel tests run in subprocesses. - RENormalizer accepts plain Python callables. - Added --slow-test option. - Added --no-progress and --auto-progress options. - Complete refactoring of the test runner into multiple code files and a more modular (pipeline-like) architecture. - Unified unit tests with the layer support by introducing a real unit test layer. - Added a doctest for ``zope.testing.module``. There were several bugs that were fixed: * ``README.txt`` was a really bad default argument for the module name, as it is not a proper dotted name. The code would immediately fail as it would look for the ``txt`` module in the ``README`` package. The default is now ``__main__``. * The tearDown function did not clean up the ``__name__`` entry in the global dictionary. * Fix a bug that caused a SubprocessError to be generated if a subprocess sent any output to stderr. * Fix a bug that caused the unit tests to be skipped if run in a subprocess. -- Benji York Senior Software Engineer Zope Corporation

4 9

zope.component: calling an Interface and calling queryAdapter give differing results
by Chris Withers 03 Oct '08

03 Oct '08

From a user's perspective, this makes no sense: >>> from zope.interface import implements,Interface >>> from zope.component import queryAdapter >>> class ISomething(Interface): pass ... >>> class MyClass: implements(ISomething) ... >>> m = MyClass() Right, so this does make sense: >>> ISomething(m) <__main__.MyClass instance at 0x00BED6E8> This does not: >>> repr(queryAdapter(m,ISomething)) 'None' why the difference? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

11 40

Make simple ISource usable
by Roger Ineichen 02 Sep '08

02 Sep '08

I'll try to make the ISource API smooth and usable for other components. Right now ISource provides no simple API for work with terms. Since a ISource only provides a __contains__ method and the IterableSource the __iter__ method, there is some more needed which makes it easy to work with terms next to the ISourceQueriables API. The zope.app.form.browser.interfaces.ITerms defines one possible way to make it work like a vocabulary because it defines the methods getTerm(value) and getValue(token). The z3c.form.interfaces.ITerms defines also such a query API but right now only or vocabularies. I propose to define such a ITerms interface in zope.schema.interfaces which makes it possible to implement simple ISource terms and work with the ITerm values like we do in vocabularies. This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms). The current state of ISource/ITerms concept whould not work if someone will switch form zope.app.form based sources to z3c.form based sources because of it's different ITerms implementations. Or if someone defines a zope.schema.ISource in a 3rd party package, the zope.app.form.browser.interfaces.ITerms is often used for query ITerms even if it's only used in python code without any form framework. That's a real bad dependency. Fazit, The only query API defined for ISource in zope.schema is the ISourceQueriables API. That's defently to less and makes it required to implement custom query APIs in UI frameworks if we need to work with terms. I no one objects, I'll start a zope.schema branch and let you know about the progress and a hopfully a simple solution. Additional to them I started allready a z3c.form branch for adjust the ITerms implementation. As far as I can see right now this refactoring will only provides additional features. What do you think? Any objections or hints about that? Regards Roger Ineichen _____________________________ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile +41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email roger.ineichen(a)projekt01.ch _____________________________ END OF MESSAGE

6 22

Re: [Zope-dev] SVN: Zope2.buildout/trunk/ Don't pin setuptools.
by Tres Seaver 02 Sep '08

02 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Schulze wrote: > Log message for revision 90415: > Don't pin setuptools. > Moved zope3.cfg to versions-zope3.cfg. > Added some missing files from the Zope2 trunk. > Added dummy script which will be used to create lib/python. <snip/> > Modified: Zope2.buildout/trunk/buildout.cfg > =================================================================== > --- Zope2.buildout/trunk/buildout.cfg 2008-08-27 09:32:04 UTC (rev 90414) > +++ Zope2.buildout/trunk/buildout.cfg 2008-08-27 09:33:59 UTC (rev 90415) > @@ -6,20 +6,12 @@ > test > omelette > find-links = http://download.zope.org/distribution/ > -unzip = true I don't think zipped eggs are a win in any real scenario, except possibly the goofy file-count-limited GAE. I would strongly prefer that you revert this one change (you can override it in your own '~/.buildout/default.cfg'). 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 iD8DBQFItvsO+gerLs4ltQ4RAhyAAJsHs5HAQkPXNJvsfD0iFZeklVS4SgCffjyb aptTF4I+sOOeCSJV2uMuIm0= =vILK -----END PGP SIGNATURE-----

4 3

Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
by Fred Drake 01 Sep '08

01 Sep '08

On Fri, Aug 29, 2008 at 5:13 PM, Malthe Borch <mborch(a)gmail.com> wrote: > Log message for revision 90599: > Move test-dependencies to 'extras'. This is a controversial change; can we avoid making changes like this until a policy is agreed upon? The controversy surrounding this has been discussed on zope-dev several times; I don't want to rehash it *right now*, since we all have things we need to get done. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

7 11

weird release of transaction module
by Martijn Faassen 31 Aug '08

31 Aug '08

Hi there, I just looked at the PyPI page of 'transaction': http://pypi.python.org/pypi/transaction And I see some weirdnesses: * it's called 'transaction 1.0a1' * the 'changes' claim however: 1.0 (unreleased) What's up? Clearly something went wrong during the releasing of this package, at least documentation-wise. Should be fixed. Note that zope.sqlalchemy pulls in this package as a dependency, even though I don't think ZODB 3.8 comes with that version of transaction... Regards, Martijn

6 5

Possible bug in zope.sqlalchemy - missing commit()
by Hermann Himmelbauer 31 Aug '08

31 Aug '08

Hi, I'm experiencing some possible bug with sqlalchemy here: - I query for some data - Update some data - Make no flush (autoflush is set to False) Then no commit is issued, hence my data is not updated in the database. At least, I looked at the function "tpc_vote" and put some print statement there and self.tx seems to be None, therefore, no commit() is issued. If I do a session.flush() after the updates, the session is perfectly commited. Does anyone know why and what I can do about it? Best Regards, Hermann -- hermann(a)qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7

2 1

Zope Tests: 5 OK
by Zope Tests Summarizer 31 Aug '08

31 Aug '08

Summary of messages to the zope-tests list. Period Sat Aug 30 11:00:00 2008 UTC to Sun Aug 31 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: Sat Aug 30 20:52:01 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010090.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 30 20:53:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010091.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 30 20:55:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010092.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 30 20:56:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010093.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sat Aug 30 20:58:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010094.html

1 0

Problems with schema Date field - year is truncated
by Hermann Himmelbauer 31 Aug '08

31 Aug '08

Hi, I'm somehow stuck on the following problem: I defined a Date() schema field in one of my interfaces. I currently have a de-AT locale, so I'd like to enter the value of my date as e.g. "dd.MM.YYYY", e.g. "01.02.1980" in my z3c.form based form. What happens is, that the locale silently assumes a format of "dd.MM.yy", which means, that the "YY / 80" is truncated and "01.02.19" is stored in my database, when updating. So, I'd like to know if: - It is possible to change the format to "dd.MM.yyyy", which is a lot more appropriate for my application (a birth date) - Make the application more strict, meaning that no data is truncated in any case. I tried to stick my nose into i18n.locales but was somehow overwhelmed by what I found. However, the following somehow seems to explain it: </dateFormatLength > <dateFormatLength type="medium"> <dateFormat > <pattern>dd.MM.yyyy</pattern> </dateFormat> </dateFormatLength > <dateFormatLength type="short"> <dateFormat > <pattern>dd.MM.yy</pattern> </dateFormat> </dateFormatLength > Nevertheless I don't know if there's a way to select a specific dateFormat, e.g. "medium" in my case. Best Regards, Hermann -- hermann(a)qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7

2 1

z3c.form - extraction from sequence widget
by Martin Aspeli 30 Aug '08

30 Aug '08

Hi, In z3c.form.widget.SequenceWidget, we have: def extract(self, default=interfaces.NOVALUE): """See z3c.form.interfaces.IWidget.""" if (self.name not in self.request and self.name+'-empty-marker' in self.request): return [] value = self.request.get(self.name, default) if value != default: for token in value: if token == self.noValueToken: continue try: self.terms.getTermByToken(token) except LookupError: return default return value This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE). Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK. Am I missing something? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

8 18