April 2008 - Zope-Dev

Proposal: Deprecate GlobalTranslationService and FiveTranslationService
by Hanno Schlichting 26 Apr '08

26 Apr '08

Hi. I'd like to propose to deprecate the Products.PageTemplates.GlobalTranslationService module and all custom translation handling from Products.Five. Rationale: In order to bring zope.i18n translation handling to the masses, some backwards compatibility code for PlacelessTranslationService and Localizer has been added to Five. Nowadays PlacelessTranslationService trunk doesn't need any of this BBB support anymore and everyone else has switched to using direct zope.i18n translations, making the BBB code unnecessary. This will remove another difference in the Zope2 PageTemplates Expression context moving them closer to the zope.tales implementation. Implementation: Deprecation warnings will be added and the code marked for deletion in two releases with a minimum of a 12 month timespan. Opinions, comments? Hanno

1 0

Proposal: Merge philikon-aq branch into Zope trunk
by Hanno Schlichting 26 Apr '08

26 Apr '08

Hi. I'd like to propose to merge the philikon-aq branch into Zope trunk aka Zope 2.12. Scope: For those unfamiliar with the branch, it makes Acquisition aware of __parent__ pointers. This makes it unnecessary to use Acquisition mixin's for Zope 3 code to use them in Zope 2 code. The security machinery of Zope 2 will still be able to work as expected. Status: All tests in the Zope itself pass. New tests have been written for all edge cases found during the development of the branch. As a real world exposure Plone has been used to test the branch. All tests in Plone except one edge-case of a monkey-patch loaded package still pass. Plone in current versions make heavy use of Zope 3 and Five technologies inside Zope 2, so I see this as a very good indicator for the readiness of the branch. The one edge-case is something which needs to be fixed in Plone, as it doesn't make use of any official API. Risks: Using Zope 3 code inside Zope 2 has lead to various 'inventive solutions' to work around problems. Some of these have not used official API's. It is possible that some of those might need to be adjusted. Adjusting them should be straight forward in most cases and mostly consist of removing the hackish workarounds. The second problem that might arise, is that the implicit assumption that every object inside Zope 2 inherits from Acquisition base classes no longer holds. Code that relies on the various aq_* attributes to be there need to be adjusted to use the Acquisition methods instead. This change is trivial to do and doesn't need to be done at first. It only needs to be done when you want to allow direct Zope 3 code in your application. As part of the branch all code in Zope 2 itself have been adjusted to use the aq_* methods. Timeline: I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems. Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. Opinions, votes? Hanno P.S. Thanks to philiKON for doing most of the work on this branch :)

13 26

new zope.org, sphinx, and documentation management
by Paul Carduner 26 Apr '08

26 Apr '08

Hi All, <lots of small talk follows, scroll down to **** section for the main point of this email> I guess I have officially volunteered to write content for the new zope.org site in the zope 3 section. Part of that involves describing what zope 3 is in a concise manner. I realize there are probably a lot of different opinions about what zope 3 is, so I would like to solicit the community to provide me with some ideas of what zope 3 is to you. It doesn't have to be anything fancy or publishable, just a bulleted list of "what zope 3 means to me" would be fine. I will aggregate these ideas and try to present it in an easy to read form. I don't want to start any arguments about what zope 3, so let's wait until I have something written before we start arguing :). Besides giving the 10000 foot view of zope 3, there is also a section for zope 3 documentation on the new site, which should probably include detailed developer documentation along with tutorials, howtos, references, etc. Fortunately, a little known fact is that there is already a fair amount of up-to-date documentation about many zope3 packages in the form of doctests (some better written for end-user consumption than others). Few people know about this because the documentation is not aggregated anywhere (except for some bits on apidoc.zope.org) You have to know to look on svn.zope.org or pypi pages to find the rest of it. Rather than writing a bunch of new documentation on the new zope.org site from scratch, I would like to harness the existing documentation, and just publish it in a nice way. To this end I have taken a look at sphinx, the new documentation publishing tool used by python.org. In short, it looks really good, and I think we could use it for zope documentation. Here is my thinking: Keeping *lots* of documentation maintained in any CMS or wiki style website is hard, because the people writing the code want to maintain everything (including documentation) in one place: subversion. It is too much to ask every developer to update a website every time they make a change to the codebase, because the website lives in firefox, while the code lives in vim or emacs. But if the documentation lives with the code, updating the documentation can become part of the normal flow of writing software (just like writing tests is part of the normal flow). So ideally, all package specific documentation *including tutorials and other end user docs* should live along side the code in subversion. Now the trick is just publishing this documentation. ***** THE POINT OF THIS EMAIL IS BELOW ***** I would like to develop a buildout recipe that generates aggregated documentation for a package (like z3c.form) using sphynx and publishes it to the new zope.org website. I want updating of zope documentation on zope.org to be as easy as uploading a package to pypi: When you are ready to make a release of a package, you would then do: $ cd z3c.form/tags/2.0/ $ python setup.py register sdist upload $ ./bin/buildout $ ./bin/update-documentation You would then be able to go to http://www.zope.org/projects/zope3/documentation/z3c.form and see everything from developer docs, to tutorials, to how-tos, etc. What do people think of this idea and who wants to help me implement it this weekend? -- Paul Carduner http://www.carduner.net

7 15

Zope Tests: 5 OK
by Zope Tests Summarizer 26 Apr '08

26 Apr '08

Summary of messages to the zope-tests list. Period Fri Apr 25 11:00:00 2008 UTC to Sat Apr 26 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: Fri Apr 25 21:01:27 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009460.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 25 21:02:57 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009461.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 25 21:04:27 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009462.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 25 21:05:57 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009463.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Fri Apr 25 21:07:27 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009464.html

1 0

comments on DateTime(DateTime()) preserving timezone? (launchpad 200007)
by Paul Winkler 26 Apr '08

26 Apr '08

I've got a fix, with tests, for https://bugs.launchpad.net/zope2/+bug/200007 checked in at Zope/branches/slinkp-datetime-200007 If nobody objects in the next few days, I'd like to merge this to trunk, and the 2.11, 2.10, and 2.9 branches. -- http://www.slinkp.com

2 1

ZConfig 2.5.1 test failures
by Timothy Selivanow 25 Apr '08

25 Apr '08

I'm getting a Traceback when running `python setup.py test` for ZConfig-2.5.1 as per the changelog. Attached is the output, let me know how I can help. I'm not a proficient python programmer; however, I'm more than willing to learn more. --Tim _________________________________________________________________ / They collapsed ... like nuns in the street ... they had no teen \ \ appeal! / ----------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).

4 7

Why I dislike narrative doctests
by Marius Gedminas 25 Apr '08

25 Apr '08

Suppose I find a bug (say, zope.testing.testrunner.StartUpFailure objects make unittest.TextTestRunner cry). Being a good developer I want to start the bug fix with a unit test. Now if zope.testing used old-style isolated unit tests, I could open the tests.py (or tests/test_testrunner.py) in a text editor and start writing: class OptionsStub(object): post_mortem = False def doctest_StartUpFailure(): """Test that StartUpFailure is a proper unittest.TestCase StartUpFailure is a TestCase-lookalike that is inserted into the test suite to indicate that a failed import of a test module won't be unnoticed. >>> from zope.testing.testrunner import StartUpFailure >>> options = OptionsStub() >>> module_name = 'test_me' >>> exc_info = (ImportError, ImportError('zonkulator'), None) >>> test = StartUpFailure(options, module_name, exc_info) >>> unittest.TextTestRunner(verbosity=2).run(test) This is a regression test for http://launchpad.net/bugs/221151 """ There, I'm almost done. Now I can fix the bug and paste the correct output into the doctest. But zope.testing uses narrative doctests instead of isolated unit tests. There are 22 plain-text files that together comprise over 4500 lines of text. Now instead of mechanically opening the appropriate test module and grepping for the class/function name I have to figure out which of the txt files is the appropriate place for the new test. After that I have to figure out how to insert it into the narrative seamlessly. Or decide to create a new file---but a hundred of .txt files each 20-lines long is not a good idea, in my opinion. Suddenly I almost don't want to fix the bug any more. While I was writing this, I suddenly realised that almost all zope.testing's txt files are actually functional tests. There are nearly no unit tests there. Perhaps that's what causing me pain. I still maintain that: * adding a new unit test should be a trivial task * extending a narrative doctest is not a trivial task * the only way to solve this conflict is to explicitly separate unit tests (test_*.py) from doctest-enhanced API documentation (*.txt). Marius Gedminas -- UNIX is user friendly. It's just selective about who its friends are.

8 18

registering adapters and subscribers for string labels
by Chris Withers 25 Apr '08

25 Apr '08

Hi All, I bumped into hurry.workflow yesterday and was reminded again that we often have the need to register components against string labels. As an example, I want to register a subscriber to a particular workflow transition. Now, the hurry.workflow examples I've seen seem to revolve around a generic subscriber with a load of if-then-else logic in them - exactly the kind of stuff the component architecture is designed to avoid ;-) (not only that, it's *really* inefficient too) So, I dug up some code I wrote to get around this and thought I'd throw it out to the list. I have a feeling this should ship somewhere, but I don't know where. Any suggestions? (if you look you'll see the code is all tested with a nice little narrative doctest in actions.py and a selection of unit tests for the edge cases in the test file, should keep even Marius happy ;-) ) cheers, Chris PS: I showed Kapil this code yesterday and he asked "why screw with globals". The answer is to allow the registrations against names to be made in zcml - as you can see in the doctest. I'm open to other suggestions for this ;-) -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk """ This module contains class singletons for any actions that we want to register adapters against. >>> from actions import register,get To create a new one: >>> register('foo') 'foo' To get hold of one once it's been registered: >>> get('foo') <Action:'foo'> And why do we want to do all this? Well, so we can register adapters against string constants like workflow actions: >>> do_zcml(''' ... <adapter ... for="test_actions.SomeClass actions.foo" ... provides="test_actions.ISomething" ... factory="test_actions.SomethingAdapter" ... /> ... ''') Now we can get an adapter as follows: >>> from test_actions import SomeClass,ISomething >>> from zope.component import getMultiAdapter >>> o = SomeClass() >>> getMultiAdapter((o,get('foo')),ISomething) <SomethingAdapter for (<SomeClass instance>, <Action:'foo'>)> """ from new import classobj registry = {} class Action: def name(self): return self.__class__.__name__ def __repr__(self): return '<Action:%r>' % self.name() def get(name): return registry[name] def register(name): if not registry.has_key(name): mod_name = name.replace(' ','_') if mod_name in globals(): raise ValueError( '%r is not available for registration as an action name' % mod_name ) k = classobj(name,(Action,),{}) registry[name]=k() globals()[mod_name]=k return name from actions import get,register,Action from unittest import TestCase,TestSuite,makeSuite from zope.app import component from zope.component import provideAdapter from zope.configuration import xmlconfig from zope.interface import Interface,implements from zope.testing.doctest import DocTestSuite class SomeClass: def __repr__(self): return '<SomeClass instance>' class ISomething(Interface): pass class SomethingAdapter: implements(ISomething) def __init__(self,*args): self.args = args def __repr__(self): return '<SomethingAdapter for %s>' % repr(self.args) def do_zcml(text): xmlconfig.string((''' <configure xmlns="http://namespaces.zope.org/zope"> %s </configure> '''%text).strip(),xmlconfig.file('meta.zcml',component)) class Tests(TestCase): def test_get(self): # we test a bogus get here, a kosher one is tested # in test_register self.assertRaises(KeyError,get,'bogus') def test_register(self): name = register('foo') self.assertEqual(name,'foo') obj = get('foo') self.failUnless(isinstance(obj,Action)) self.assertEqual(obj.name(),'foo') self.assertEqual(repr(obj),"<Action:'foo'>") def test_duplicate_register(self): register('foo') obj1 = get('foo') register('foo') obj2 = get('foo') self.failUnless(obj1 is obj2) def test_adapter(self): register('foo bar') xmlconfig.string(''' <configure xmlns="http://namespaces.zope.org/zope"> <adapter for="actions.foo_bar" provides="test_actions.ISomething" factory="test_actions.SomethingAdapter" /> </configure> '''.strip(),xmlconfig.file('meta.zcml',component)) a = ISomething(get('foo bar')) self.failUnless(isinstance(a,SomethingAdapter)) self.assertEqual(len(a.args),1) self.failUnless(a.args[0] is get('foo bar')) def test_register_bad(self): self.assertRaises(ValueError,register,'Action') self.assertRaises(ValueError,register,'get') self.assertRaises(ValueError,register,'register') self.assertRaises(ValueError,register,'registry') def test_suite(): suite = TestSuite() suite.addTest(makeSuite(Tests)) suite.addTest(DocTestSuite('actions', globs={'do_zcml':do_zcml})) return suite

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 25 Apr '08

25 Apr '08

Summary of messages to the zope-tests list. Period Thu Apr 24 11:00:00 2008 UTC to Fri Apr 25 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: Thu Apr 24 21:03:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009455.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:05:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009456.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:06:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009457.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:08:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009458.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 24 21:09:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009459.html

1 0

paver and buildout
by Kevin Dangoor 24 Apr '08

24 Apr '08

Hi, So, I saw Martijn's "paver: buildout is utterly doomed" message on Tuesday, but I haven't had a chance to respond to it until now. As Kent points out immediately following, I plan to use zc.buildout's machinery. I actively use zc.buildout now, and I'm looking forward to getting my buildout merged into my pavement.py. I totally agree with Martijn that buildout needs a better website and I'm glad to see that Baiju is going forward with that. Ultimately, though, I think that people will choose to use buildout alone or paver+buildout (or maybe paver+virtualenv, depending on their tastes) completely based on what fits their brains better. I emailed a fair bit with Zed Shaw about his Vellum tool. He adamantly opposes having his builds defined in a full-blown language (ie Python), whereas for my needs I really want to define my builds in Python. But I want it to be easier to do than what you get with the Python standard library. People who prefer to keep there build information in a "data" format will no doubt stick with buildout. I have no problem with that. My goal is just to share the workload with other people who have similar build and deployment problems to the ones I have. Kevin

2 1