August 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.testing: Define __add__ for RENormalizing
by Christian Zagrodnick 06 Dec '09

06 Dec '09

Hi, I suggest defining __add__ for zope.testing.renormalizing.RENormalizing which would return a new Checker with the transformers combined. This allow better reuse of those checkers without having to define the patterns separately. Like checker = checker_a + checker_b. Comments? -- Christian Zagrodnick · cz(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development

3 3

Proposal: zope.app.publisher refactoring
by Dan Korostelev 30 Nov '09

30 Nov '09

Hi all. I think it's time to clean the mess in the zope.app.publisher package. Currently it contains many things that could be moved into separate packages or merged with base zope packages. So here's a sketch plan about where to move things: Menu mechanism (the browser:menuItem directive and friends) - move this to the new "zope.browsermenu" package. This should be easy as nothing else in zope.app.publisher seem to depend on menus. Browser view directives (browser:page and friends) - move this to some "zope.browserpage" package and make its structure more clean, so people could understand the magic of browser page class generation. :-) BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary. ManagementViewSelector (the @@SelectedManagementView.html view) - leave it there as is. Resource mechanism (files, directories, etc.) - probably the most complicated code, but it should be easy to move it to the new "zope.browserresource" package. One problem is with PageTemplateResource that introduces a dependency on zope.pagetemplate. It should probably moved to another package, like "zope.ptresource" and made dependent on z3c.ptcompat to support chameleon engine. ModifiableBrowserLanguages implementation - move to zope.publisher.browser. It's the useful thing that won't introduce any new dependencies. "date" fieldconverter - I don't think anyone uses it, I'd leave it there as is and forget about it :) http.zcml - this file contains security declarations for zope.publisher's HTTP-related classes. move them to zope.publisher. xmlprc - move the IXMLRPCView interface and XMLRPCView base class to zope.publisher as a counterpart to zope.publisher.browser.BrowserView. Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to new "zope.xmlrpcview" package. Also I'd merge MethodTraverser with MethodPublisher to make it easier to understand and to decrease number of entities :) IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?) IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well. ILogin, ILogout from zope.app.publisher.interfaces.http - looks like these don't really mean anything and are used only in zope.app.security. I'd move them to zope.app.security even without BBB imports (not to make zope.app.publisher dependent on zope.app.security), but maybe I just don't know something about them? :) That's all for now. I'd like to see some comments/propositions/objections before I start. Also, maybe there are more beautiful names for new packages? After refactorings it will be much easier to clean and develop features that are currently provided by zope.app.publisher. For instance I'd like to try to simplify browser resources code somewhat, but it's for another proposal :) -- WBR, Dan Korostelev

8 23

zc.relationship - can't pickle module objects
by Martin Aspeli 09 Nov '09

09 Nov '09

Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? zc.relationship.index.Index's initialiser: def __init__(self, attrs, defaultTransitiveQueriesFactory=None, dumpRel=generateToken, loadRel=resolveToken, relFamily=IFBTree, deactivateSets=False): self._name_TO_mapping = OOBTree.OOBTree() # held mappings are objtoken to (relcount, relset) self._EMPTY_name_TO_relcount_relset = OOBTree.OOBTree() self._reltoken_name_TO_objtokenset = OOBTree.OOBTree() self.defaultTransitiveQueriesFactory = defaultTransitiveQueriesFactory self._relTools = getModuleTools(relFamily) self._relTools['load'] = loadRel self._relTools['dump'] = dumpRel self._relLength = Length.Length() self._relTokens = self._relTools['TreeSet']() self.deactivateSets = deactivateSets self._attrs = _attrs = {} # this is private, and it's not expected to # mutate after this initial setting. seen = set() for data in attrs: # see README.txt for description of attrs. if zope.interface.interfaces.IElement.providedBy(data): data = {'element': data} res = getModuleTools(data.get('btree', IFBTree)) res['element'] = val = data['element'] res['attrname'] = val.__name__ res['name'] = data.get('name', res['attrname']) if res['name'] in _attrs or val in seen: raise ValueError('Duplicate in attrs', name, val) seen.add(val) _attrs[res['name']] = res res['dump'] = data.get('dump', generateToken) res['load'] = data.get('load', resolveToken) if (res['dump'] is None) ^ (res['load'] is None): raise ValueError( "either both of 'dump' and 'load' must be None, or neither") # when both load and dump are None, this is a small # optimization that can be a large optimization if the returned # value is one of the main four options of the selected btree # family (BTree, TreeSet, Set, Bucket). res['interface'] = val.interface res['multiple'] = data.get('multiple', False) res['call'] = zope.interface.interfaces.IMethod.providedBy(val) if res['TreeSet'].__name__.startswith('I'): Mapping = IOBTree.IOBTree else: assert res['TreeSet'].__name__.startswith('O') Mapping = OOBTree.OOBTree self._name_TO_mapping[res['name']] = Mapping() # these are objtoken to (relcount, relset) Regards, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 15

Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
by yuppie 27 Oct '09

27 Oct '09

Hi! SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path. So this no longer works in zopectl: ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" Therefore mkzopeinstance now creates something like this: ZDCTL="/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" Problem: -------- - the code in mkzopeinstance.py that looks up the Zope2 path fails on some platforms - if the software is updated, you have to change the paths in runzope and zopectl of each instance Solution: --------- 1.) Add two new entry points in setup.py: runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:run If the software is installed, executable runzope and zopectl files are created in the bin directory. That should work with zc.buildout and with easy_install. 2.) Modify the runzope and zopectl files created by mkzopeinstance: The result should look like this: ZDCTL="/path/to/install/bin/zopectl" exec "$ZDCTL" -C "$CONFIG_FILE" "$@" mkzopeinstance would make the assumption that executable runzope and zopectl files exist in the same directory as mkzopeinstance itself. Risks: ------ - mkzopeinstance has a --python option. The specified Python interpreter will no longer be used to execute runzope or zopectl. - uses cases might exist that no longer work after that change Any thoughts? Is the 2.12 branch still open for changes like that? Cheers, Yuppie

7 22

whitespace filtering corner case in doctest
by Reinout van Rees 16 Sep '09

16 Sep '09

In some cases, importing readline can result in the escape code ^[[?1034h to be send ("8bit on"). This escape code isn't visible, which leads to hard to find test errors, see http://reinout.vanrees.org/weblog/2009/07/16/invisible-test-diff.html Granted, it are basically corner cases. On the other hand, it does seem to cause problems now and then, according to my googling. Would it be ok to add it to the whitespace normalization of doctests? Opinions? Reinout -- Reinout van Rees - reinout(a)vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"

2 4

Update on ztk kgs: Python 2.6 issues
by Jim Fulton 16 Sep '09

16 Sep '09

I've gotten the ztk kgs tests to pass with Python 2.5 on Mac OS X. I've got them mostly passing with on Python 2.6. The only failure I'm getting is for zope.testing and it's due to a Python 2.6 hotshot bug: http://bugs.python.org/issue6710 I'm not sure what to do about this. Perhaps I should disable this test, or maybe even the feature for Python 2.6. When building, I'm getting some deprecation warnings: /Users/jim/.buildout/eggs/infrae.subversion-1.4.5-py2.6.egg/infrae/subversion/Common.py:4: DeprecationWarning: the sets module is deprecated from sets import Set # For python 2.3 compatibility /Users/jim/.buildout/eggs/z3c.recipe.compattest-0.7-py2.6.egg/z3c/recipe/compattest/recipe.py:4: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import popen2 It would be great if someone would fix these. :) When running the tests, the only deprecation warnings are from twisted, which we can't do anything about. BTW, if you want to try this yourself, use the buildout at: svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs Jim -- Jim Fulton

3 4

zc.buildout, substitution and templating
by Encolpe Degoute 12 Sep '09

12 Sep '09

Hello, These last days I was using collective.recipe.template and gocept.recipe.env. The second one just update options with os.environ. Unix shell having their own substitution methods then '${' appearing in the .installed.cfg. It just blows if you try to rerun 'bin/buildout. As zc.buildout is using something near string.template I patched gocept.recipe.env to replace '$' by '$$' and collective.recipe.template to replace '$$' by '$'. As _sub method in builout just split text around '$$' and join it again with '$$' we need to make the replacement with the result of this method. Is it the good way to deal with escaping data ? Or is this a bug of zc.buildout ? Regards, -- Encolpe DEGOUTE http://encolpe.wordpress.com/ http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales

4 5

chameleon.core removes the meta http-equiv="content-type" tag
by Fabio Tranchitella 10 Sep '09

10 Sep '09

Hello, I hope this is the right mailing list for such a question. Why does chameleon.core removes the meta tag http-equiv="content-type" from the output? In template.py, line 286: # Look for an encoding specification in the meta tag match = utils.re_meta.search(body) if match is not None: content_type, encoding = match.groups() # TODO: Shouldn't <meta>/<?xml?> stripping # be in PageTemplate.__call__()? body = utils.re_meta.sub("", body) else: content_type = None encoding = config.DEFAULT_ENCODING I couldn't find the explanation anywhere in the source code nor in the documentation. Thanks, Fabio

6 7

Re: [Zope-dev] Move implementation of getParent to zope.location?
by Jim Fulton 09 Sep '09

09 Sep '09

On Wed, Aug 12, 2009 at 5:56 AM, Thomas Lotze<thomas(a)thomas-lotze.de> wrote: > Jim Fulton <jim(a)zope.com> schrieb: > >> I object to removing API functions that client code might use. (Was >> that a trick questions?) What is the point of this exercise? > > Sorry, this message shouldn't have been sent in the state it was. > > The original point of the exercise was to clean up the situation where > the two closely related functions aren't part of the same APIs. Then I > responded to the suggestion of removing the functions, noticing two > things as I wrote: the functions are used by zope.app packages, and > they are part of zope.traversing.api but not used by anything > non-zope.app. As api-style modules have been questioned in the past, I > wanted to raise the issue whether the functions are meant to remain > part of that module or live in the ILocationInfo interface alone, but I > got distracted at that point and for some reason sent the message, > which I shouldn't have done. > > If the functions remain in the api module, the remaining issue would be > whether to move the implementation of getParent to zope.location and > thus treat it like getParents. Right. I understood this in the original proposal. Given that it doesn't break the existing API, I have no major problem with it, which is why I didn't bother to respond in the first place. I have a small problem that it fattens an existing API. I have a larger problem that we are wasting time on this. The cleanup doesn't seem worth it to me. I especially don't like that *I'm* spending time on this rather than, say, working on the kgs or our buildout discussions. Jim -- Jim Fulton

2 1