- Zope-Dev - Zope lists

Zope3 and Generic Functions
by Paul Wilson 02 Jan '10

02 Jan '10

Hi there, I've been really getting my head around Zope3 and adaption lately for a talk for my local Python usergroup. I've read quite a bit on the topic, but of particular interest was the adapter vs. generic function debate that's been doing the rounds over the last few years. See Guido van Rossum's article here: http://www.artima.com/weblogs/viewpost.jsp?thread=155123 where he concludes that generic functions are more general and useful. Further, we have Ian Bicking's Zope 3 critique where, he argues that generic functions are generally better and Martijn Faassen's comment: "I agree by the way that generic methods are interesting and we should be investigating how they fit in a Zope 3 context." There is a clear relationship between the two, and after some brainstorming with Chris McDonough on the Zope IRC channel, I've been able to write an @generic(TypeA, TypeB, ... , TypeN) decorator that uses the Zope component registry to supply such behaviour. It's become clear to me that named multiadapters are essentially the same concept as generic functions, and in a Zope context, are actually more powerful because you can specify *interfaces* as well as concrete types as part of the function's type-signature: @generic(IFoo, IBar, TypeA, TypeB, ...). I don't know if this relationship is already known in the Zope world, and if people are already doing this? Is there any value in something like this? It's pretty 'deep' stuff, so I've written a tutorial (Chris's idea) that goes through the thought process towards writing the generic function decorator with Zope tools - please find attached. We think it might make a nice (supplementary) addition to upcoming zope.component narrative documentation (there is upcoming documentation... right?). To confirm the idea I wrote a basic little script too, which I've attached also. You can see that @generic works with types, interfaces or both - thanks to the zope.component machinery. Any thoughts would be great! Paul

2 1

zope.testing.doctestunit pprint and deprecation warnings
by Martijn Faassen 01 Jan '10

01 Jan '10

Hi there, zope.testing.doctestunit emits a deprecation warning. It also defines a function pprint. How does one use pprint without getting a deprecation warning? It seems impossible now, and an equivalent pprint doesn't appear to be in the standard library doctest.. Regards, Martijn

5 5

Zope Tests: 6 OK
by Zope Tests Summarizer 01 Jan '10

01 Jan '10

Summary of messages to the zope-tests list. Period Thu Dec 31 12:00:00 2009 UTC to Fri Jan 1 12:00:00 2010 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 31 20:36:52 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013299.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Dec 31 20:38:52 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013300.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 31 20:40:52 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013301.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 31 20:42:52 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013302.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 31 20:44:52 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013303.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Dec 31 20:46:52 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013304.html

1 0

Re: [Zope-dev] zope.contenttype on PyPI is messed up
by Hanno Schlichting 31 Dec '09

31 Dec '09

On Thu, Dec 31, 2009 at 2:56 PM, Fabio Tranchitella <fabio(a)tranchitella.eu> wrote: > ... things changed now: both 3.4.3 and 3.5.0 are visible; this morning when > I checked, only 3.4.3 was visible, and thus my buildbot warned me that some > dependencies in the ZTK were unsatisfied (and buildout tried to download > 3.4.3 instead of 3.5.0). What? setuptools and zc.buildout only use the simple view of packages based on http://pypi.python.org/simple/ and then linking to http://pypi.python.org/simple/zope.contenttype. This page always shows all releases and doesn't care about the visibility status setting. The PyPi pages are only for humans looking at packages. If your buildbot warns or downloads 3.4.3 then there's something very funny going on with your buildbot. The current way PyPi shows packages to humans is obviously not optimal, but not doing the tedious extra work and twiddling around with those visibility status settings hardly counts as messing up. I'm not aware of any release policy that requires us to do this extra step. Hanno

1 0

zope.contenttype on PyPI is messed up
by Fabio Tranchitella 31 Dec '09

31 Dec '09

Can somebody please fix zope.contettype on PyPI? We had a 3.5.0 release, and somebody uploaded a 3.4.3 release which should have been 3.5.1. I don't have the rights for it. Best regards, Fabio

4 3

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

31 Dec '09

Summary of messages to the zope-tests list. Period Wed Dec 30 12:00:00 2009 UTC to Thu Dec 31 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 30 20:36:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013293.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Dec 30 20:38:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013294.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:40:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013295.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:42:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013296.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:44:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013297.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 30 20:46:55 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013298.html

1 0

Top-level namespace package for Zope 2 ?
by Baiju M 31 Dec '09

31 Dec '09

Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ? Well, I don't have any name suggestion :) Regards, Baiju M

4 5

Re: [Zope-dev] SVN: Zope/branches/2.10/doc/CHANGES.txt - fixed improper usage of the IF_MODIFIED_SINCE header inside
by Tres Seaver 31 Dec '09

31 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Log message for revision 107357: > - fixed improper usage of the IF_MODIFIED_SINCE header inside > Five/browser/resource.py > > > Changed: > U Zope/branches/2.10/doc/CHANGES.txt > > -=- > Modified: Zope/branches/2.10/doc/CHANGES.txt > =================================================================== > --- Zope/branches/2.10/doc/CHANGES.txt 2009-12-30 13:16:54 UTC (rev 107356) > +++ Zope/branches/2.10/doc/CHANGES.txt 2009-12-30 13:19:39 UTC (rev 107357) > @@ -4,6 +4,14 @@ > Change information for previous versions of Zope can be found in the > file HISTORY.txt. > > + Zope 2.10.11 (unreleased) > + > + Bugs fixed > + > + - fixed improper usage of the IF_MODIFIED_SINCE header inside > + Five/browser/resource.py > + > + > Zope 2.10.10 (2009/12/22) No fix for this issue has landed yet on the 2.10 branch. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks8FtEACgkQ+gerLs4ltQ5LyQCeL/KfsJFy8yK8q3SNdGeqW8/9 6wgAoKnSPP4v455jXr5h/Xka8biA5C4I =HuBu -----END PGP SIGNATURE-----

1 0

Re: [Zope-dev] SVN: Zope/branches/2.11/ - Fixed improper handling of IF_MODIFIED_SINCE header
by Tres Seaver 31 Dec '09

31 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Log message for revision 107356: > - Fixed improper handling of IF_MODIFIED_SINCE header > inside Five/browser/resource.py > > > Changed: > U Zope/branches/2.11/doc/CHANGES.txt > U Zope/branches/2.11/lib/python/Products/Five/browser/resource.py What, no test? How do you know you got the speling right? And why use 'request.environ.get()' instead of the original OFS.Image spelling, 'request.get_header()'? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks8FS8ACgkQ+gerLs4ltQ5UewCgnwP21URcTj/AfX1tRl6vsKj2 cQIAn3oPGaIX4VOK8UIErPu8Hk9kHpLu =bAkx -----END PGP SIGNATURE-----

1 0

removing zope.app from the ZTK
by Martijn Faassen 30 Dec '09

30 Dec '09

Hi there, Fastest summary: * removing responsibility from the ZTK, yes, but not like this. Quick summary: * I agree we should dump most, perhaps all, of the code that is in zope.app.* from the ZTK. Most of these packages will likely eventually become unmaintained. * We as a community have a responsibility to help the users of our software to help get to a world with a vastly smaller set of zope packages. We can't just ignore that responsibility. * we can make a plan about when we will declare a lot of packages without support, after we've had some more experience with upgrading code. Longer: Here's my position on the role of zope.app within the ZTK and in our community. We as the Zope community have been maintaining Zope 3 for years now. We have a lot of software that depends on it. Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. As part of the dependency refactoring project, we've been factoring code out of zope.app.* packages that we do use and leaving the old zope.app.* packages behind. A philosophical point: just because we have a dependency structure that *allows* us to remove zope.app.* from the dependency tree of the ZTK doesn't mean that only zope.* contains useful code that can be shared between our community. It's been a convenient shortcut to think in this way, but it isn't necessarily the case that we're done moving code out of zope.app.* into zope.*. I'll ignore this point below and assume that zope.app.* only contains old stuff that we don't want to maintain in the future. Recently the zope.app.* packages were entirely removed from the ZTK. That we wish to remove zope.app.* from the ZTK at some point follows from the previous discussion, but as a community, I think we've certainly done this step too fast. Since this is a *big* change and was done without sufficient discussion, I've reverted this change and added these packages back into the ZTK, in the "under review" section where they were before, and back to the versions list. We need to maintain zope.app.* for the time being to help people off zope.app. We can't just drop the ball on this and offer no support. The argument was made that the Zope 2 project has already taken care of this, and that other projects that use Zope 3 should also maintain their own backwards compatibility list separately and just work out their own upgrade stories. This is exactly one of those jobs we should do centrally, and not delegate to subcommunities. That's neglecting our responsibility as a community and ignoring a *value* of our community. In what form we should maintain the zope.app.* packages? I can see a construction where the main ZTK consists only of non-zope.app packages and that we, as ZTK developers, maintain a separate project for zope.app.*. This way we can continue to maintain and test this project as a community, and help people with a smooth upgrade. We cannot just stop testing whether this works, or stop maintaining versions that work together. And that's what we did. We can make a plan as to when we *will* officially drop support for these packages, or hand over maintainership to others, etc, and how we will help our community to get there. Our plan doesn't need to be perfect; we can expect some difficulty in this upgrade, but we should at least make a reasonable attempt. Regards, Martijn

8 32