Zope-Dev November 2009

zope-dev@zope.dev

45 participants
59 discussions

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

Testrunner option for running tests in random order?!?
by Christian Theune 23 Dec '09

23 Dec '09

Hi, I *thought* the test runner had a feature to run tests in randomized order, but I can't find it. Is that something that Zope 2 had and that was never ported to zope.testing? I couldn't find in the history either. /me is confused. -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

5 15

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

implementing zope.component 4.0
by Martijn Faassen 05 Dec '09

05 Dec '09

Hi there, Introduction ------------ So now that we've had some discussion and to exit the "bikeshed" phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible. This means that I'll ignore backwards compatibility while sketching out the "ideal semantics" below - I have the impression we can get consensus on the following behavior: Simple adaptation: IFoo(adapted) Named adaptation: IFoo(adapted, name="foo") Adaptation with a default IFoo(adapted, default=bar) Multi-adaptation: IFoo(one, two) Named multi adaptation: IFoo(one, two, name="foo") Multi-adaptation with a default: IFoo(one, two, default=bar) Utility lookup: IFoo() Named utility lookup: IFoo(name="foo") Utility lookup with a default: IFoo(default=bar) Where "name" and "default" can be combined. The name and default keyword parameters have to be used explicitly - *args is interpreted as what to adapt only. Any other keyword parameters should be rejected. Utility lookups versus adapter lookups -------------------------------------- There was some discussion on whether utility lookups are really something fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: "give me an instance that implements IFoo", and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. Features off the table for now ------------------------------- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. Backwards compatibility ----------------------- Now let's get back to my favorite topic in this discussion: backwards compatibility. The ideal semantics unfortunately break backwards compatibility for the single adapter lookup case, as this supports a second argument, the default. The challenge is therefore to come up with a way to support the new semantics without breaking the old. We could introduce the following upgrade pattern: zope.component 3.8.0: old semantics zope.component 3.9: old semantics is the default. new semantics supported too somehow but explicitly triggered. zope.component 4.0: new semantics is the default. Old semantics is not supported anymore. We could, if needed, maintain zope.component 3.x in parallel with the new-semantics 4.0 line for a while. A per-module triggering of the new semantics might be done like this: from zope.component.__future__ import __new_lookup__ Is that implementable at all however? Someone needs to experiment. Alternatively we could do something special when we see this: IFoo(foo, bar). This is ambiguous - is the new semantics in use or the old one? If the adapter cannot be looked up using multi adaptation we *could* fall back on single adaptation under the assumption that the old semantics are desired. But this will lead to a problem if the new semantics *was* desired but the component simply could not be found. I think it's important not to do a "big bang" upgrade but instead allow people to upgrade bit by bit. It should be possible to compose an application that mixes code that expects the old semantics with code that expects the new semantics. A bit by bit upgrade I think would ideally be on a per-module basis. I think it's important to make sure we can support such an upgrade *before* we release any of this. Conclusions ----------- Are people okay with the proposed semantics? Would people be okay with such an upgrade path? Any better ideas? Most importantly, any volunteers? Regards, Martijn

25 131

improving the utility and adapter lookup APIs
by Martijn Faassen 03 Dec '09

03 Dec '09

Hi there, Reading the thread Chris McDonough started (and ended) about modifying the way utility registration works reminded me of the following thinking. It's quite independent and probably even antithetical to Chris's approach as it uses interfaces, but that's fine. The goal is to make it easier to look up certain componenty things. The goal is to have to import from "zope.component" as little as possible for lookups. Just import interfaces and you'll be done. I think it makes sense to make the lookup operation disappear into the "language" as much as we can make them. I know we've had this kind of discussion before, but let's get something working this time around. So I'm also looking for volunteers to help out with the implementation. I'm going to ignore registration APIs for now in this discussion. While they can be improved too, we have ZCML and martian-style registration systems that can handle that ok. Let's focus on lookup APIs first. We have a nice way to look up a single adapter: from foo import IFoo IFoo(object) Unfortunately, this breaks down when you want to look up a multiadapter: from foo import IFoo from zope import component component.getMultiAdapter((x, y), IFoo) That's an extra import and a lot more typing. We also have it break down when you want to look up a utility: from zope import component component.getUtility(IFoo) So let's look at ways to hook this up to interfaces. Adapter: IFoo(x) Adapter with default: IFoo(x, default=default) So far it's all supported. (I think. It's hard to find the code that supports this.. hints?) Named adapter: IFoo(x, name='something') Multiadapter: IFoo.multi(x, y) Multiadapter with default: IFoo.multi(x, y, default=default) Named multiadapter: IFoo.multi(x, y, name='something') Utility: IFoo.utility() [or possibly IFoo() instead?] Utility with default: IFoo.utility(default=default) [or IFoo(default=default)?] Named utility: IFoo.utility(name='something') [or IFoo(name='something')?] As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass I know Jim had some objections towards implementation of this in an earlier discussion, but later changed his mind. So I'm going to look at Jim for hints about implementing this. :) If we do well we might all have this for Christmas. :) Thoughts? Regards, Martijn

21 55

Releasing zope.browserresource
by Thomas Lotze 02 Dec '09

02 Dec '09

Could somebody please give me PyPI rights for zope.browserresource? I'd like to release a new version of it which includes the recent fixes to its dependencies. Thank you very much. -- Thomas

7 11

Object schema field validation
by Markus Kemmerling 01 Dec '09

01 Dec '09

I stumbled upon a problem with Object schema field validation. The problem occurs, e.g., if the the Object field's schema itself contains a Choice field with a dynamically computed vocabulary. For the latter to validate correctly the field must be bound to the instance. But the Object field validation code in zope.schema._fields._validate_fields validates the attributes of the Object field instance without binding them first: def _validate_fields(schema, value, errors=None): ... try: attribute = schema[name] if IField.providedBy(attribute): # validate attributes that are fields attribute.validate(getattr(value, name)) except ValidationError, error: ... Replacing the line attribute.validate(getattr(value, name)) with field = attribute.bind(value) field.validate(getattr(value, name)) fixes the problem. Looks like a bug to me. Regards, Markus Kemmerling

2 1

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

Zope Tests: 6 OK
by Zope Tests Summarizer 30 Nov '09

30 Nov '09

Summary of messages to the zope-tests list. Period Sun Nov 29 12:00:00 2009 UTC to Mon Nov 30 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: Sun Nov 29 20:38:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013107.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Nov 29 20:40:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013108.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:42:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013109.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:44:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013110.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:46:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013111.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:48:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013112.html

1 0

Zope Tests: 6 OK
by Zope Tests Summarizer 29 Nov '09

29 Nov '09

Summary of messages to the zope-tests list. Period Sat Nov 28 12:00:00 2009 UTC to Sun Nov 29 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: Sat Nov 28 20:39:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013101.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Nov 28 20:41:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013102.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:43:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013103.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:45:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013104.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:47:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013105.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:49:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013106.html

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev November 2009