December 2009 - Zope-Dev

Get rid of doctest.py in zope.testing? (Was: Bootstrapping ZCA for Python 3.)
by Lennart Regebro 08 Dec '09

08 Dec '09

I started a new branch for porting zope.testing to Python 3, for several reasons, mostly because I got confused and decided starting over with a clean copy and beginning with the new Distribute python 3 support from start would make me less foncused (it worked). The branches aren't that different in the end, obviously: http://svn.zope.org/zope.testing/branches/regebro-python3-reloaded/ There are 19 tests that doesn't pass yet (and that's mostly doctest tests, so there are many actual failures), and most of those are based in formatting differences when it comes to doctests. For example: Exceptions in Python 3 print out the whole module path of the exception, while in Python 2 it's only the classname: Immediate doctest failure. This is fixable in your doctests by trapping the exception instead, which is what I've done. However: Many of the failing tests are tests to check that the doctest module works. In the other modules I've ported, the doctest module has been included because it wasn't included in Python 2.3, and could simply be dropped with Python 2.3 support. However, in zope.testing doctests are slightly modified and also tested. So many of the failing tests are tests that doctest behave properly, and that the output formatting is OK. Which, of course, it is not. There are other differences too. The diff module seems to add empty lines at the end sometimes, which bugger up the output, especially in the colorful formatter tests. Efforts to remove doctests failed on the INTERPRET_FOOTNOTES options, which the standard Python doctests doesn't support. A quick search turns out that ZODB, zc.catalog, zc.relation, zc.async, zc.sharing, zc.freeze and lovely.remotetask uses it, maybe more. I really think it's a bad idea to have a special version of doctest.py. I think we should get rid of it. That means either dropping this feature, or getting it merged into Python 2.7 and 3.2. The 2.7 beta is out now, so it's pretty urgent. I strongly suspect it's going to be practically impossible to support zope.testing from the same test-base otherwise. Opinions? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

4 8

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

08 Dec '09

Summary of messages to the zope-tests list. Period Mon Dec 7 12:00:00 2009 UTC to Tue Dec 8 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: Mon Dec 7 20:38:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013155.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Dec 7 20:40:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013156.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 7 20:42:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013157.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 7 20:44:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013158.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 7 20:46:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013159.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 7 20:48:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013160.html

1 0

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

07 Dec '09

Summary of messages to the zope-tests list. Period Sun Dec 6 12:00:00 2009 UTC to Mon Dec 7 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 Dec 6 20:38:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013149.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Dec 6 20:40:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013150.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sun Dec 6 20:42:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013151.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Dec 6 20:44:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013152.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sun Dec 6 20:46:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013153.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Dec 6 20:48:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013154.html

1 0

zope.testing.testrunner.debug.post_mortem and try/finally
by Ross Patterson 07 Dec '09

07 Dec '09

When a try/finally clause is (appropriately) used to do cleanup after an exception during a test run, it often tears down parts of the fixture that are needed in order to do useful post_mortem debugging of the exception, such as closing the request or db connections. What is the best way to do post_mortem debugging with the stack in the state it was at the time of the exception? For a while now, I've been repeatedly modifying eggs in my development environment at the relevant try/finally clauses to invoke post_mortem before the tear down is done, sub-optimal to say the least. :) I find myself doing it often its time to invest in a better way. Is there some Python voodoo I'm unaware of to get a post_mortem to reflect the stack before try/finally clauses? If not, is putting some sort of hook into the relevant try/finally clauses the best way to address this? If not, what should I be doing? If putting hooks into the try/finally clauses is the right way, then it would be nice to have a somewhat canonical way to do this. It would also be nice to have a way to pass something down the line so that post_mortem() only gets called once per exception. Thoughts, Ross

6 13

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

06 Dec '09

Summary of messages to the zope-tests list. Period Sat Dec 5 12:00:00 2009 UTC to Sun Dec 6 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 Dec 5 20:38:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013143.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Dec 5 20:40:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013144.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 5 20:42:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013145.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 5 20:44:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013146.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 5 20:46:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013147.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 5 20:48:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013148.html

1 0

Zope Tests: 4 OK, 2 Unknown
by Zope Tests Summarizer 06 Dec '09

06 Dec '09

Summary of messages to the zope-tests list. Period Fri Dec 4 12:00:00 2009 UTC to Sat Dec 5 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Unknown ------- Subject: UNKNOWN : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Fri Dec 4 20:48:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013139.html Subject: UNKNOWN : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Dec 4 20:50:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013140.html Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Dec 4 20:44:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013137.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Dec 4 20:46:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013138.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Fri Dec 4 20:52:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013141.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Dec 4 20:54:07 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013142.html

4 3

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