December 2009 - Zope-Dev

Manuel Beta
by Benji York 14 Jan '11

14 Jan '11

I've just released the first beta of Manuel, my next-generation doctest project. Being that zope-dev has some of the most well-informed users of doctest (and some of the most well-informed non-users of doctest), I'd like to gather feedback from this group before making an announcement to the wider world. Manuel is available from PyPI (http://pypi.python.org/pypi/manuel) with docs, details, and examples at http://packages.python.org/manuel/. I'm interested in any feedback and/or questions you may have be it technical, documentation, or "marketing" (i.e., how do I describe what Manuel does and what benefits it has). -- Benji York Senior Software Engineer Zope Corporation

5 12

Zope 3.4 and the way forward
by Marius Gedminas 26 Jan '10

26 Jan '10

So, what's the way forward for existing Zope 3.4 (KGS) users? Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK? Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0? Band together and release a ZopeApp 1.0 KGS which would be a strict superset of the ZTK 1.0? (In which case, why not call it Zope 3.5 KGS?) Forget all this open-source sharing stuff and maintain our own separate versions.cfg files with ad-hoc version mixes? Personally, I'd prefer option 1 (if there were docs to tell me what to do to get rid of zope.app, which is implausible) or option 2. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development

5 4

windows newslines in doctests
by Chris Withers 11 Jan '10

11 Jan '10

Hi All, I've run into problems with Windows newlines in doctests a couple of times now and so thought I'd ask what people do in general to work around this... Do you: - make sure .txt that ends up being doctested only has \n line endings in it? - use zope.testing.renormalizing to replace \r\n with \n? - something else I'm not aware of :-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 9

zope.app.form and zope.formlib
by Martijn Faassen 11 Jan '10

11 Jan '10

Hi there, I've been trying to clean up the zope.formlib/zope.app.form situation. This is a report about my lack of progress so far, just so I have something to show for it. :) zope.app.form is in practice in use as a widget library for zope.formlib. It however also contains code that supports the original Zope 3 form system (using ZCML directives). My first response was to try to move zope.app.form's widgets into zope.formlib. zope.app.form can then depend on zope.formlib for its widgets (for backwards compatibility), and zope.formlib would stop depending on zope.app.form. We can leave the old Zope 3 form system behind. I started to try this but was daunted by having to port a huge amount of code from zope.app.form to zope.formlib, including test code. Instead, I tried to create a zope.formlibwidget which which would contain only the widgets of zope.app.form. zope.app.form would then depend on it for backwards compatibility, and zope.formlib would only need to depend on zope.formlibwidget. Unfortunately this bounced off the fact that zope.app.form's functional widget tests (there are many, we want to retain them) depend on the old Zope 3 form support in order to do their tests. The old Zope 3 form support I was trying to get rid of in the first place. To do sane functional tests I need a form library. I can't use zope.formlib in zope.formlibwidget as that would create a circular dependency (at least for tests, but that's ugly enough). So my conclusion is to move zope.app.form's widget stuff into zope.formlib, so that the functional tests can be ported to use zope.formlib instead of the old Zope 3 form system. So I'm back to my original approach again... Regards, Martijn

4 4

small manuel bugfix
by Chris McDonough 06 Jan '10

06 Jan '10

I added a branch of manuel to the Zope SVN that fixes the codeblock plugin when you use codeblock "roles" such as: .. code-block:: python :linenos: Currently it only works without roles, e.g.: .. code-block:: python The branch is at svn+ssh://svn.zope.org/repos/main/manuel/branches/chrism-codeblocks The diff against the current head is as follows: [chrism@snowpro manuel]$ svn diff =================================================================== --- src/manuel/codeblock.py (.../branches/chrism-codeblocks) (revision 107071) +++ src/manuel/codeblock.py (.../trunk) (revision 107071) @@ -2,9 +2,7 @@ import manuel import textwrap -CODEBLOCK_START = re.compile( - r'(^\.\.\s*(invisible-)?code-block::?\s*python\b(?:\s*\:\w+\:)*)', - re.MULTILINE) +CODEBLOCK_START = re.compile(r'^\.\.\s*(invisible-)?code-block::?\s*python\b', re.MULTILINE) CODEBLOCK_END = re.compile(r'(\n\Z|\n(?=\S))') @@ -15,8 +13,7 @@ def find_code_blocks(document): for region in document.find_regions(CODEBLOCK_START, CODEBLOCK_END): - start_end = CODEBLOCK_START.search(region.source).end() - source = textwrap.dedent(region.source[start_end:]) + source = textwrap.dedent('\n'.join(region.source.splitlines()[1:])) source_location = '%s:%d' % (document.location, region.lineno) code = compile(source, source_location, 'exec', 0, True) document.claim_region(region) I submit it for Benji's consideration.

2 6

Where best to intercept a request to send a 304 response in Zope 2
by Martin Aspeli 06 Jan '10

06 Jan '10

Hi, A few of us are playing with some caching tools, trying to get to a more sane and less monkey patch-laden approach than CacheFu (Products.CacheSetup), for use with Zope 2.12. It is relatively easy to set response headers, e.g. in an IPubBeforeCommit event handler. However, we also need to be able to intercept a request to send a 304 response if the underlying object has not been modified. CacheFu monkey patches ZPT rendering to avoid the actual rendering if a 304 response is being sent, returning an empty string instead. I'd rather not have such patches, though, and anyway this only work with things rendered as ZPTs. It also doesn't avoid any pre-work that a view may do before rendering its template, if indeed it has one. Another thought was to use IPubAfterTraversal, at which point we have the object to publish and security checks have been completed. However, ZPublisher.Publish goes straight from that into mapply(). Can anyone think of a good way to do this? Maybe we need to add some kind of condition around mapply(), e.g. to do not nothing if there's a 304 response header, or some other marker? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 4

Possible Zope 2.12 regression - Five page templates use restrictedTraverse for TAL
by Martin Aspeli 05 Jan '10

05 Jan '10

Hi, Ages ago, I started a thread (I think on this list) about the use of TAL expression in Zope 3-style page templates (i.e. ViewPageTemplateFile's used on views) incorrectly performing security checks when using TAL expressions. I think Tres fixed it at the time (I can't find the original mail), but in Zope 2.12.2 there seems to have been a regression. I'd like to make sure I've not missed something, though. I see the problem in Plone 4.0a2 on Zope 2.12, trying to use plone.app.registry. This package has a class that derives from plone.registry.registry.Registry (a "ZTK-only" version) and SimpleItem (to get Zope 2 security and ZMI visibility). Otherwise, it does nothing. There is a view for this class registered like this: <browser:page name="view" for="plone.registry.interfaces.IRegistry" template="records.pt" permission="cmf.ManagePortal" /> In records.pt, there is the following: <tr tal:repeat="record context/records/values"> ... </tr> This fails with the stack trace below. However, if I change it to use a python: expression, it's all fine: <tr tal:repeat="record python:context.records.values()"> ... </tr> As you can see from the stack trace, the TAL expression has resulted in the use of restrictedTraverse(). I think it should be using unrestrictedTraverse(), since ViewPageTemplateFile's are filesystem code. (In this particular case, it's failing the restrictedTraverse check because 'records' is a property and so doesn't have an aq chain, but nevermind that). Stack trace: 2009-12-13 00:40:13 ERROR Zope.SiteErrorLog 1260636013.580.4115611559 http://localhost:8080/test/portal_registry/@@view Traceback (innermost last): Module ZPublisher.Publish, line 127, in publish Module ZPublisher.mapply, line 77, in mapply Module Products.PDBDebugMode.runcall, line 70, in pdb_runcall Module ZPublisher.Publish, line 47, in call_object Module Products.Five.browser.metaconfigure, line 427, in __call__ Module Products.Five.browser.pagetemplatefile, line 126, in __call__ Module Products.Five.browser.pagetemplatefile, line 60, in __call__ Module zope.pagetemplate.pagetemplate, line 115, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 888, in do_useMacro Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 533, in do_optTag_tal Module zope.tal.talinterpreter, line 518, in do_optTag Module zope.tal.talinterpreter, line 513, in no_tag Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 888, in do_useMacro Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 533, in do_optTag_tal Module zope.tal.talinterpreter, line 518, in do_optTag Module zope.tal.talinterpreter, line 513, in no_tag Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 946, in do_defineSlot Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 533, in do_optTag_tal Module zope.tal.talinterpreter, line 518, in do_optTag Module zope.tal.talinterpreter, line 513, in no_tag Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 954, in do_defineSlot Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 533, in do_optTag_tal Module zope.tal.talinterpreter, line 518, in do_optTag Module zope.tal.talinterpreter, line 513, in no_tag Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 946, in do_defineSlot Module zope.tal.talinterpreter, line 343, in interpret Module zope.tal.talinterpreter, line 819, in do_loop_tal Module zope.tales.tales, line 682, in setRepeat Module zope.tales.tales, line 696, in evaluate - URL: /Users/optilude/Development/Plone/Instances/Clients/Lotterywest/osc/src/plone.app.registry/plone/app/registry/browser/records.pt - Line 33, Column 12 - Expression: <PathExpr standard:u'context/records/values'> - Names: {'args': (), 'container': <Registry at /test/portal_registry>, 'context': <Registry at /test/portal_registry>, 'default': <object object at 0x1002c7b50>, 'here': <Registry at /test/portal_registry>, 'loop': {}, 'nothing': None, 'options': {}, 'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0x108e8b3b0>, 'request': <HTTPRequest, URL=http://localhost:8080/test/portal_registry/@@view>, 'root': <Application at >, 'template': <Products.Five.browser.pagetemplatefile.ViewPageTemplateFile object at 0x10792b950>, 'traverse_subpath': [], 'user': <PropertiedUser 'admin'>, 'view': <Products.Five.metaclass.SimpleViewClass from /Users/optilude/Development/Plone/Instances/Clients/Lotterywest/osc/src/plone.app.registry/plone/app/registry/browser/records.pt object at 0x10885c810>, 'views': <Products.Five.browser.pagetemplatefile.ViewMapper object at 0x108cbb0d0>} Module zope.tales.expressions, line 217, in __call__ Module Products.PageTemplates.Expressions, line 127, in _eval Module zope.tales.expressions, line 124, in _eval Module Products.PageTemplates.Expressions, line 76, in boboAwareZopeTraverse Module OFS.Traversable, line 312, in restrictedTraverse Module OFS.Traversable, line 247, in unrestrictedTraverse - __traceback_info__: ([], 'records') Unauthorized: You are not allowed to access 'records' in this context > /Users/optilude/.buildout/eggs/Zope2-2.12.1-py2.6-macosx-10.6-i386.egg/OFS/Traversable.py(247)unrestrictedTraverse() Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 7

zope.testing 3.8.6 emits deprecation warnings from itself?
by Chris Withers 03 Jan '10

03 Jan '10

Hi, I hate DeprecationWarnings at the best of times, since no one actually does anything about them until whatever they're bleating about is actually gone anyway, but zope.testing has outdone itself. Whoever introduced that warning, if you're going to do so, please solve any problems with code in the actual package itself before releasing. zope.testing.testrunner.debug imports doctest from zope.testing and so bleats whenever tests are run with zope.testing 3.8.6. Why was 3.8.6 released when it still emits these warnings itself? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

5 15

zope.testing.doctestunit pprint and deprecation warnings
by Martijn Faassen 01 Jan '10

01 Jan '10

Hi there, zope.testing.doctestunit emits a deprecation warning. It also defines a function pprint. How does one use pprint without getting a deprecation warning? It seems impossible now, and an equivalent pprint doesn't appear to be in the standard library doctest.. Regards, Martijn

5 5

Re: [Zope-dev] zope.contenttype on PyPI is messed up
by Hanno Schlichting 31 Dec '09

31 Dec '09

On Thu, Dec 31, 2009 at 2:56 PM, Fabio Tranchitella <fabio(a)tranchitella.eu> wrote: > ... things changed now: both 3.4.3 and 3.5.0 are visible; this morning when > I checked, only 3.4.3 was visible, and thus my buildbot warned me that some > dependencies in the ZTK were unsatisfied (and buildout tried to download > 3.4.3 instead of 3.5.0). What? setuptools and zc.buildout only use the simple view of packages based on http://pypi.python.org/simple/ and then linking to http://pypi.python.org/simple/zope.contenttype. This page always shows all releases and doesn't care about the visibility status setting. The PyPi pages are only for humans looking at packages. If your buildbot warns or downloads 3.4.3 then there's something very funny going on with your buildbot. The current way PyPi shows packages to humans is obviously not optimal, but not doing the tedious extra work and twiddling around with those visibility status settings hardly counts as messing up. I'm not aware of any release policy that requires us to do this extra step. Hanno

1 0