March 2009 - Zope-Dev

Python3 and attribute annotations.
by Dan Korostelev 13 Mar '09

13 Mar '09

Hi zope developers! As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things. But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict. I think that it's a good time now to start thinking about problems like this, because there's a lot of time before zope will be used in python 3.0, so we can prepare to move without much problems. So, I propose to change annotation storage attribute to "__zope_annotation__" and make AttributeAnnotation adapter automatically migrate data from __annotations__ to __zope_annotations__. I think that adding "zope" to the attribute name will avoid any name clashes in future. I'd like to hear about problems that this change can possibly introduce (__slots__, security proxies, etc.) and maybe some more community ideas on that. -- WBR, Dan Korostelev

6 10

Zope Tests: 6 OK
by Zope Tests Summarizer 13 Mar '09

13 Mar '09

Summary of messages to the zope-tests list. Period Thu Mar 12 12:00:00 2009 UTC to Fri Mar 13 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:28:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011259.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:30:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011260.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:32:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011261.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 12 21:34:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011262.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 12 21:36:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011263.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 12 21:39:00 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011264.html

1 0

z3c.form - creating a file upload widget
by Martin Aspeli 13 Mar '09

13 Mar '09

Hi, I'm writing a custom file widget for z3c.form that works like the Archetypes file widget that Plone uses and the formlib widget in collective.namedfile. That is, after you've uploaded a file once, you're given a radio button to decide whether to upload a new file, or leave the existing file in place. I can't quite figure out how to do this, though. I've tried to override the extract() method on the widget to look in the request for the special marker that says "user chose not to change the file". However, I don't know what to return. If I return NOVALUE, then validation fails (if the field is required). If I try to look up the field value from the data manager and return it, it ends up setting the field back on itself, which is wasteful. Any clues? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 6

deprecating the deprecation system?
by Martijn Faassen 12 Mar '09

12 Mar '09

Hi there, Perhaps it's time to deprecate the deprecation system. Why? * I've had good experience in the Grok project with just noting changes that might break code in the upgrade notes for Grok and telling people how to fix it. Using documentation more background can be provided and it can become a lot more clear what to do. * using the deprecation system requires quite a bit of effort, as we're adding code. Do we test deprecations? That's quite a bit of energy spent there that we could instead spend on documentation. * it's a zope-specific system no other Python projects use. Now we'll need some of them, but do we need this one? * we've not been very good at removing old deprecations over time. * the deprecation system's messages have traditionally not been of a high quality. I recall occasions where it told me half of what to do, and certainly won't give me any background on what is going on. * for moving code around we have an alternative system: a backwards compatibility import, documentation about what to do, and a tool part of the test runner which can point out indirect imports. I therefore propose we do the following: * look at any package which uses deprecation warnings now. * rip out the deprecation warnings and backwards compatibility code. Even if it's really expiring in 2010 (I doubt we have much of this). When you do so and you think anyone might still using that code path, please make a remark in zope3docs/source/migration/34to35.rst about what's going on and what people are to do. * run the compattests to see whether anything breaks. I think it's quite possible some deprecated code is in use by the Zope libraries themselves. :) Thoughts? Regards, Martijn

7 15

Release of zope.component (was [Checkins] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch)
by Dan Korostelev 12 Mar '09

12 Mar '09

I decided to start a new branch of that, because there's no still response on my requests for a release. Here's the last message: > Let's decide that and make a release of zope.component so we could > move forward on adapting other packages to recent removal of BBB > interfaces. > > Here's three variants: > > * Move pure python implementation to zope.hookable as a fallback. > * Move C implementation to zope.component and drop zope.hookable > dependency at all. > * Just drop zope.hookable dependency, providing only pure python > version of hookable. > > The second (or even third, if there's no significant slowdown) variant > seems fine to me personally, because, as Tres noted, there's probably > no consumers for zope.hookable beyond zope.component, so we can safely > merge the packages. > > Jim, Philipp, Marius, can you please give us rights on PYPI for > zope.component. My account is "nadako" there, so you can give it to me > and I'll add other people. -- WBR, Dan Korostelev

3 7

New package: zope.authentication AND the problem.
by Dan Korostelev 12 Mar '09

12 Mar '09

Hey, community. As a part of zope.app.security refactoring process, a new package has been created - "zope.authentication". It basically contains IAuthentication and other auth-related interfaces, as well as PrincipalSource. So it's intended to define a basic concepts and contracts of principal authentication for the zope framework to be implemented by other packages. There are three implementations that I know of currently: the "global principal registry" from zope.app.security (it will be moved into new package, called "zope.principalregistry"), the zope.app.authentication and z3c.authenticator. It's quite request type independent so it can be used with non-zope.publisher requests, like WebOb or something, but here the problem appears: The zope.app.security defines the ILoginPassword (getLogin,getPassword,needLogin) adapters for zope.publisher's HTTP and FTP requests. I wonder where should they go, because the "zope.authentication" package doesn't want to depend on zope.publisher, as (like i said before) it is intended to be tiny and independent on any request implemenation. I'd move those adapters into zope.publisher itself, but this will require adding the "zope.authentication" dependency for zope.publisher, which I think is okay, because zope.authentication is very small and will probably be used together with zope.publisher anyway. Another solution which I like much less is to move those adapters to "zope.authentication" and define an extra dependency (sigh) on zope.publisher, but then the package won't be so nice, clean and generic as it could be. :-) Opinions? -- WBR, Dan Korostelev

2 3

Releasing z3c.recipe.i18n?
by Brian Sutherland 12 Mar '09

12 Mar '09

Hi, I've added a oneline bugfix to z3c.recipe.i18n that's pretty important for me (97979). Could someone release it? or add me as an owner in pypi so I can do it myself? My pypi username is jinty. -- Brian Sutherland

2 1

z3c.form: nested group
by Laurent Mignon 12 Mar '09

12 Mar '09

Hi, 2 weeks ago, I've implemented a support for nested group into the branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup All test pass and no compatibility issue. Can I merge it to the trunk? Regards Laurent Mignon

5 5

z3c.form: TextLineConverter and IFromUnicode
by Martin Aspeli 12 Mar '09

12 Mar '09

Hi, Sorry for doing this by email rather than unit test, but I'm a bit over-stretched at the moment. plone.z3cform has a backport of z3c.form trunk's TextLines widget (when's that release coming, any ideas?). In using it, I discovered that the converter (converter.py on z3c.form trunk) does this: def toFieldValue(self, value): """See interfaces.IDataConverter""" widget = self.widget collectionType = self.field._type if isinstance(collectionType, tuple): collectionType = collectionType[-1] if not len(value): return self.field.missing_value valueType = self.field.value_type._type if isinstance(valueType, tuple): valueType = valueType[0] return collectionType(valueType(v) for v in value.split()) I was just wondering: should we not try to use IFromUnicode when converting the value type? This would be safer, and probably allow us to support more value_types. Arguably, we should *require* that the value_type for this widget provides IFromUnicode, but we could have the fallback _type cast like this. A simple implementation would be: def toFieldValue(self, value): """See interfaces.IDataConverter""" widget = self.widget collectionType = self.field._type if isinstance(collectionType, tuple): collectionType = collectionType[-1] if not len(value): return self.field.missing_value value_type = self.field.value_type cast = None fromUnicode = IFromUnicode(value_type, None) if fromUnicode is not None: cast = fromUnicode.fromUnicode else: cast = value_type._type if isinstance(cast, (tuple,list)): cast = cast[0] return collectionType(cast(v) for v in value.split()) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

2 2

Namespace declaration using pkgutil vs pkg_resources
by Baiju M 12 Mar '09

12 Mar '09

Hi All, Now we have 'setuptools' as a dependency for all packages. (I guess this is to make Buildout happy ?) So, it is certain that 'pkg_resources' module will be always available as it is bundled with 'setuptools'. If that is the case, why do we need a fall-back import of 'pkgutil' to declare a namespace package? So instead of: try: import pkg_resources pkg_resources.declare_namespace(__name__) except ImportError: import pkgutil __path__ = pkgutil.extend_path(__path__, __name__) Just this line would be enough to declare a namespace: __import__('pkg_resources').declare_namespace(__name__) Am I missing something ? Regards, Baiju M

7 9