- Zope-Dev - Zope lists

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

the ZCA API decision
by Martijn Faassen 05 Dec '09

05 Dec '09

Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] Hopefully we can move forward towards implementation. Thomas Lotze, are you happy enough with this to still help with the implementation? Thanks everybody for your participation in the discussion! Regards, Martijn

11 22

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

Zope Tests: 6 OK
by Zope Tests Summarizer 04 Dec '09

04 Dec '09

Summary of messages to the zope-tests list. Period Thu Dec 3 12:00:00 2009 UTC to Fri Dec 4 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 Dec 3 20:38:38 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013131.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Dec 3 20:40:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013132.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 3 20:42:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013133.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 3 20:44:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013134.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 3 20:46:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013135.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 3 20:48:39 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013136.html

1 0

ZCA summary so far...
by Gary Poster 03 Dec '09

03 Dec '09

...from my perspective. = Things vaguely approaching consensus = == General == There's a consensus that changes to the ZCA need to be backwards compatible. The practical definition of that varies for different people. == Syntactic == === Tuple multi-adaptation === Example: IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo) - It has the most consensus of any proposed change so far. - It is concerning because it breaks backwards compatibility in two real world use cases from the very small set of Zope users who actually watch zope-dev. There is a workaround spelling at least, but it is ugly (i.e., what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``). - It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I always have to look up the order of arguments for getMultiAdapter myself) but not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another spelling of the same thing (e.g., ``IFoo(bar)`` is the same as ``IFoo((bar,))``. == Utilities available from interfaces == As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see "No consensus" section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the "tuple multi-adaptation" section above. = No consensus AFAICT = - Utilities and adapters should be merged. - We care significantly about new and casual users and perceive that the current API does not serve them well. - Adapters are usually used as factories, and utilities are used as instances, and it is valuable to present them that way. Related: the term "adapter" buys us little and costs us more than nothing among new and casual users. = Rejected = - Utilities should be called singletons.

3 7

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

Zope Tests: 6 OK
by Zope Tests Summarizer 03 Dec '09

03 Dec '09

Summary of messages to the zope-tests list. Period Wed Dec 2 12:00:00 2009 UTC to Thu Dec 3 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: Wed Dec 2 20:38:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013125.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Dec 2 20:40:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013126.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:42:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013127.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:44:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013128.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:46:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013129.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:48:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013130.html

1 0

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

Zope Tests: 6 OK
by Zope Tests Summarizer 02 Dec '09

02 Dec '09

Summary of messages to the zope-tests list. Period Tue Dec 1 12:00:00 2009 UTC to Wed Dec 2 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: Tue Dec 1 20:38:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013119.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 1 20:40:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013120.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:42:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013121.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:44:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013122.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:46:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013123.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 1 20:48:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013124.html

1 0

z3c.recipe.i18n tests fail
by Christian Zagrodnick 02 Dec '09

02 Dec '09

Hi, the tests fail with the following error: Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt Traceback (most recent call last): File "/Users/zagy/development/python/lib/python2.6/unittest.py", line 270, in run self.setUp() File "/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py", line 2289, in setUp self._dt_setUp(test) File "/private/tmp/trunk/src/z3c/recipe/i18n/tests.py", line 43, in setUp zc.buildout.testing.install('zope.app.publisher', test) File "/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py", line 464, in install if dist.location.endswith('.egg'): AttributeError: 'NoneType' object has no attribute 'location' I actually have no idea why this is happening. Anybody got a clue? Regards, -- 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

2 3