[Zope-dev] Zope Tests: 65 OK, 29 Failed, 5 Unknown
Summary of messages to the zope-tests list. Period Sat Mar 19 12:00:00 2011 UTC to Sun Mar 20 12:00:00 2011 UTC. There were 99 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 29 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 5 from ct at gocept.com, 45 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Sat Mar 19 14:40:20 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035533.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Sat Mar 19 14:40:54 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035534.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sat Mar 19 14:53:20 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035541.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sat Mar 19 14:53:46 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035542.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sat Mar 19 14:54:43 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035543.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sat Mar 19 14:55:28 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035545.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sat Mar 19 15:16:49 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035553.html Subject: FAILED : winbot / zc_buildout_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sat Mar 19 17:07:39 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035577.html Subject: FAILED : winbot / zc_buildout_dev py_265_win32 From: buildbot at winbot.zope.org Date: Sat Mar 19 17:07:50 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035578.html Subject: FAILED : winbot / zc_buildout_dev py_265_win64 From: buildbot at winbot.zope.org Date: Sat Mar 19 17:08:01 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035579.html Subject: FAILED : winbot / zc_buildout_dev py_270_win32 From: buildbot at winbot.zope.org Date: Sat Mar 19 17:08:13 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035580.html Subject: FAILED : winbot / zc_buildout_dev py_270_win64 From: buildbot at winbot.zope.org Date: Sat Mar 19 17:08:25 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035581.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Sat Mar 19 18:28:19 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035586.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Sat Mar 19 18:30:40 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035587.html Subject: FAILED : winbot / z3c.ptcompat_py_265_32 From: buildbot at winbot.zope.org Date: Sat Mar 19 20:11:26 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035599.html Subject: FAILED : winbot / z3c.rml_py_265_32 From: buildbot at winbot.zope.org Date: Sat Mar 19 20:38:30 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035600.html Subject: FAILED : winbot / z3c.form_py_265_32 From: buildbot at winbot.zope.org Date: Sat Mar 19 20:51:40 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035604.html Subject: FAILED : winbot / z3c.coverage_py_265_32 From: buildbot at winbot.zope.org Date: Sat Mar 19 21:14:41 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035605.html Subject: FAILED : winbot / z3c.macro_py_265_32 From: buildbot at winbot.zope.org Date: Sat Mar 19 21:15:47 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035606.html Subject: FAILED : winbot / z3c.pagelet_py_265_32 From: buildbot at winbot.zope.org Date: Sat Mar 19 21:28:19 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035607.html Subject: FAILED : Total languishing bugs for zopeapp: 2 From: ct at gocept.com Date: Sat Mar 19 21:30:16 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035608.html Subject: FAILED : Total languishing bugs for zopetoolkit: 197 From: ct at gocept.com Date: Sat Mar 19 21:36:54 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035609.html Subject: FAILED : Total languishing bugs for zope: 53 From: ct at gocept.com Date: Sat Mar 19 21:40:31 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035610.html Subject: FAILED : Total languishing bugs for zope2: 5 From: ct at gocept.com Date: Sat Mar 19 21:45:07 EDT 2011
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sat, Mar 19, 2011 at 8:06 PM, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: ... I would be much more interested in seeing a working WebOb to zope.publisher bridge. I know Jim(?) Yes. has done some initial work on that. I think it would make an interesting PSF project, since it encourages more reusability across the Python Web dev community. Yup, although I think this has been muddied somewhat by a recent push to somehow merge webob with the request/response type used by Flask. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sat, Mar 19, 2011 at 5:02 PM, Lennart Regebro rege...@gmail.com wrote: Getting ZCA/ZTK to run on PyPy is probably easier, and actually more useful. Maybe someone would want to mentor that? This is another porting project. If I was a student, I wouldn't find it very interesting to port some code I hadn't written and probably don't understand from one platform to another. (My earlier comment on py2k-py3k porting wasn't meant as a dig against py3k bit rather to say that I didn't think porting projects would be very interesting.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro rege...@gmail.com wrote: I'm still in Atlanta, and Arc Riley asked for a Zope person to possibly mentor some zope.* project for Python Software Foundation this year. Here's another idea. Problem === ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. Solution sketch === I think we ought to come up with a much cleaner way of defining default configuration. (Pyramid does this by passing default values in adapter calls, but I think we can do a lot better than that.) I'd like to see us come up with a pythonic way to wire components up that can be overridden through registration (through zcml or otherwise). Ideally, the mechanism shouldn't feel like configuration but like programming. Note that the default configuration should provide a sort of a baseline you get by importing the module that defines it. Today, we typically treat an empty component registry as the baseline, but this new default configuration mechansim should define a baseline. How this happens and it's rules need to be worked out. Note that when I mention rules in the previous paragraph, it's because I think there need to be rules that limit the mechanism. For example, the baseline wiring should not depend on import order, meaning that one module should nor be able to override another module's default configuration. I would be interested in mentoring this project. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sun, Mar 20, 2011 at 9:49 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 20 March 2011 13:46, Jim Fulton j...@zope.com wrote: I think we ought to come up with a much cleaner way of defining default configuration. (Pyramid does this by passing default values in adapter calls, but I think we can do a lot better than that.) I'd like to see us come up with a pythonic way to wire components up that can be overridden through registration (through zcml or otherwise). Ideally, the mechanism shouldn't feel like configuration but like programming. You mean like http://pypi.python.org/pypi/grokcore.component http://pypi.python.org/pypi/grokcore.view http://pypi.python.org/pypi/grokcore.viewlet http://pypi.python.org/pypi/grokcore.security ? Hm, it's been a while since I've looked at grok. Some notes: - The mechanism I'm thinking of should not require *any* ZCML. - The mechanism shouldn't require something to grok/analyze the code. The mechanism should be explicit. This is implied by pythonic. I remember Grok being more implicit than skimming the links above suggest. Perhaps Grok has has become more explicit than I remember. - I'd prefer not to rely on subclassing, but I'm not dead set against it. - Whataever we come up with has to work with Python 3, so unfortunately, we can't use the syntactic trick of having a call in a class like:: grokcore.component.implements(IContentProvider) The effort should certainly include an analysis of approaches like grok. Maybe the mechanism should have the effect of enabling tools like grok to be implemented more cleanly. Note that the move from advice-based syntax to class decorators provides a good opportunity to revisit how some of this works based on experience using the ztk. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton j...@zope.com wrote:
- The mechanism shouldn't require something to grok/analyze the
code. The mechanism should be explicit. This is implied by
pythonic. I remember Grok being more implicit than skimming the
links above suggest. Perhaps Grok has has become more explicit than
I remember.
Both Grok and Pyramid (or martian and venusian really) do a scan of
the code to find the registration hints.
I think you cannot avoid this, if you want to support an explicit
configuration phase. Otherwise the first import of a module could
occur at any point at runtime and have a configuration side-effect
like registering a new view. Personally I find the venusian approach
pretty simple and explicit enough.
Note that the move from advice-based syntax to class decorators
provides a good opportunity to revisit how some of this works based
on experience using the ztk.
Taking one of the examples of grokcore.component, I think there's a
lot that can be made simpler:
import grokcore.component
from zope.i18n.interfaces import ITranslationDomain
class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
grokcore.component.implements(ITranslationDomain)
grokcore.component.name('helloworld')
Based on my Pyramid exposure, I'd write this as something like:
from something import utility
from zope.i18n.interfaces import ITranslationDomain
@utility(ITranslationDomain, name='helloworld')
class HelloWorldTranslationDomain(object):
pass
This does mean hardcoding default values into the registration calls.
I'm not sure I see the value of avoiding this, as long as there's a
way to unregister this utility and re-register the class with other
values.
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 3/20/11 16:00 , Hanno Schlichting wrote: On Sun, Mar 20, 2011 at 3:28 PM, Jim Fultonj...@zope.com wrote: - The mechanism shouldn't require something to grok/analyze the code. The mechanism should be explicit. This is implied by pythonic. I remember Grok being more implicit than skimming the links above suggest. Perhaps Grok has has become more explicit than I remember. Both Grok and Pyramid (or martian and venusian really) do a scan of the code to find the registration hints. Pyramid only does so if you tell it to do so by using config.scan(). You are not obliged to do that, and I have several pyramid projects which do not do any scanning. Not doing scanning has the advantage of making configuration more explicit, and it speeds application startup immensely. Scanning is needed if you want to mix configuration and code in one place. That may not be the right model for everyone. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 3/20/11 16:03 , Wichert Akkerman wrote: On 3/20/11 16:00 , Hanno Schlichting wrote: On Sun, Mar 20, 2011 at 3:28 PM, Jim Fultonj...@zope.com wrote: - The mechanism shouldn't require something to grok/analyze the code. The mechanism should be explicit. This is implied by pythonic. I remember Grok being more implicit than skimming the links above suggest. Perhaps Grok has has become more explicit than I remember. Both Grok and Pyramid (or martian and venusian really) do a scan of the code to find the registration hints. Pyramid only does so if you tell it to do so by using config.scan(). You are not obliged to do that, and I have several pyramid projects which do not do any scanning. Not doing scanning has the advantage of making configuration more explicit, and it speeds application startup immensely. Let me try to argue this better. Downsides of scanning are: - it scans your tests, which can result in unexpected behaviour you may not expect (at least for venusian, not sure if this is true for martian). - you may have some draft files in your tree that are not ready for use and never referenced anywhere, but a scan will still process them. - scanning can take a long time, making application (re)start slow for non-trivial projects - problems in the scanning process tend to be very hard debug. If a view is not processed during scanning figuring out why can be painful, and there are little to no tools to help you. This is especially true for more complex scanning environments such as the plone/dexterity/z3cform stack; as an example I spent over an hour yesterday trying to figure out why a form was not picked up while other views in the same python file worked fine. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichting ha...@hannosch.eu wrote:
On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton j...@zope.com wrote:
- The mechanism shouldn't require something to grok/analyze the
code. The mechanism should be explicit. This is implied by
pythonic. I remember Grok being more implicit than skimming the
links above suggest. Perhaps Grok has has become more explicit than
I remember.
Both Grok and Pyramid (or martian and venusian really) do a scan of
the code to find the registration hints.
I think you cannot avoid this, if you want to support an explicit
configuration phase. Otherwise the first import of a module could
occur at any point at runtime and have a configuration side-effect
like registering a new view. Personally I find the venusian approach
pretty simple and explicit enough.
I disagree. First, the notion that you'd import at run time is pretty odd,
unless you count start-up in runtime.
Second, well, really, I'm not ready to give up on a straightforward
definition of wiring that doesn't rely on module scanning.
Note that the move from advice-based syntax to class decorators
provides a good opportunity to revisit how some of this works based
on experience using the ztk.
Taking one of the examples of grokcore.component, I think there's a
lot that can be made simpler:
import grokcore.component
from zope.i18n.interfaces import ITranslationDomain
class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
grokcore.component.implements(ITranslationDomain)
grokcore.component.name('helloworld')
Based on my Pyramid exposure, I'd write this as something like:
from something import utility
from zope.i18n.interfaces import ITranslationDomain
@utility(ITranslationDomain, name='helloworld')
class HelloWorldTranslationDomain(object):
pass
This does mean hardcoding default values into the registration calls.
I'm not sure I see the value of avoiding this, as long as there's a
way to unregister this utility and re-register the class with other
values.
Yup.
Also, If there's an existing mechanism that does what I want and I'm
just ignorant of, I'd be happy to learn about it. If such a thing
exists or can be cobbled together from existing ideas, I'd like to
elevate it either as part of the ZCA or as a best-practice tool that
stands independent of any particular application framework.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
Hi,
On 20 March 2011 15:00, Hanno Schlichting ha...@hannosch.eu wrote:
On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton j...@zope.com wrote:
- The mechanism shouldn't require something to grok/analyze the
code. The mechanism should be explicit. This is implied by
pythonic. I remember Grok being more implicit than skimming the
links above suggest. Perhaps Grok has has become more explicit than
I remember.
Both Grok and Pyramid (or martian and venusian really) do a scan of
the code to find the registration hints.
I think you cannot avoid this, if you want to support an explicit
configuration phase. Otherwise the first import of a module could
occur at any point at runtime and have a configuration side-effect
like registering a new view. Personally I find the venusian approach
pretty simple and explicit enough.
Note that the move from advice-based syntax to class decorators
provides a good opportunity to revisit how some of this works based
on experience using the ztk.
Taking one of the examples of grokcore.component, I think there's a
lot that can be made simpler:
import grokcore.component
from zope.i18n.interfaces import ITranslationDomain
class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
grokcore.component.implements(ITranslationDomain)
grokcore.component.name('helloworld')
Based on my Pyramid exposure, I'd write this as something like:
from something import utility
from zope.i18n.interfaces import ITranslationDomain
@utility(ITranslationDomain, name='helloworld')
class HelloWorldTranslationDomain(object):
pass
This does mean hardcoding default values into the registration calls.
I'm not sure I see the value of avoiding this, as long as there's a
way to unregister this utility and re-register the class with other
values.
I agree - this is nicer. In Grok's defence, class decorators didn't
exist when martian was conceived. :)
I do wonder whether it's nicer *though*, though, to justify yet more
proliferation of configuration syntax.
I appreciate that in Python 3 the in-class advice (which was pioneered
by zope.component/zope.interface, don't forget) may not work properly,
so we may not have any choice eventually. But saving two lines of code
in a hypothetical example doesn't necessarily outweigh the confusion
that comes from having multiple ways to do things, and grokcore.*
configuration is in use in the wild outside of Grok.
Martin
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
Hi, On 20 March 2011 15:29, Jim Fulton j...@zope.com wrote: I think you cannot avoid this, if you want to support an explicit configuration phase. Otherwise the first import of a module could occur at any point at runtime and have a configuration side-effect like registering a new view. Personally I find the venusian approach pretty simple and explicit enough. I disagree. First, the notion that you'd import at run time is pretty odd, unless you count start-up in runtime. I think Hanno was saying that configuration at import time is unpredictable and leads to ordering problems and circular import type risks. This shouldn't really be a surprise to anyone. Second, well, really, I'm not ready to give up on a straightforward definition of wiring that doesn't rely on module scanning. I recall Chris suggesting some improvements of the zope.configuration API to make it user friendly. Right now, it only really makes sense in the context of writing ZCML directives. Pyramid has largely done that work, though I'm not sure how compatible it is at this point in time. With a cleaner, better documented zope.configuration API, you can do configuration in your __main__ function or whatever works on startup. One option then is to use the indirection of ZCML or the indirection of martian/venusian style scanning, which may make sense for frameworks and pluggable apps, but less sense for more closed systems. Then again, it feels like Pyramid has largely done this already. ;-) Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sun, Mar 20, 2011 at 4:29 PM, Jim Fulton j...@zope.com wrote: I disagree. First, the notion that you'd import at run time is pretty odd, unless you count start-up in runtime. Right, sorry. I'm used to writing add-ons for an application. In this environment my code isn't in charge of the startup process, but will be called sometime in the middle of it. Some of your code might be imported early, some very late. In this sort of unpredictable environment, scanning comes in handy. Once some of your code is called, you can ensure to scan and register all of it. Second, well, really, I'm not ready to give up on a straightforward definition of wiring that doesn't rely on module scanning. Sure. I didn't mean to exclude this. Pyramid allows you to do a very explicit configuration without any scanning. If you write an application and have full control over all its parts, this works. Things get complicated, once you reuse libraries which in turn have other library dependencies with configuration actions. Ignore the naming for the moment. You could call these application components, arguing that a library shouldn't have any hard configuration requirements. Currently we have an explicit approach via providing a configure.zcml in each library, which causes all relevant parts to be imported and hooked up. One library can include the ZCML of another library or a subpackage of its own. Either each library provides a similar central place, which imports all its modules with configuration actions, or you use the scanning approach to avoid the explicit mechanism. Also, If there's an existing mechanism that does what I want and I'm just ignorant of, I'd be happy to learn about it. If such a thing exists or can be cobbled together from existing ideas, I'd like to elevate it either as part of the ZCA or as a best-practice tool that stands independent of any particular application framework. I think venusian, the venusian actions and the configuration machinery of Pyramid come pretty close to this. Personally I think we could extract these and roll them back into the ZTK. Maybe there's something in Grok that comes close to this. I've just not been able to distinguish the Grok the web framework code with its convention over configuration idea from some basic explicit configuration approach. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2011 09:46 AM, Jim Fulton wrote: Problem === ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. Solution sketch === I think we ought to come up with a much cleaner way of defining default configuration. (Pyramid does this by passing default values in adapter calls, but I think we can do a lot better than that.) I'm not confident that better is achievable for the classic dependency injection case (i.e., the default is the one you almost always want, except for unit testing). Typically, I define a utility interface *and* the default implementation in the module which mostly uses it. E.g.:: from zope.interface import Interface from zope.component import queryUtility class ISomePlugPoint(Interface): def __call__(foo, bar): blah blah # Look, Ma! No decorator! def defaultImpl(foo, bar): # DTRT for the normal case def clientFunction(request): impl = queryUtility(ISomePlugPoint, default=defaultImpl) Note the absence extra declarations for 'defaultImpl', and of extra syntax of any kind. In order to maintain good test isolation, I usually avoid memoizing the lookup (e.g. as a module scope variable). unless profiling shows that the lookup ends up on a critical path. This pattern even works outside of testing: if you do the frameworky thing and document how to override the utility as a policy, it becomes a trivial integration point. For adapters, the example is a bit noisier, because the component registry wants to call the factory for you:: from zope.interface import Interface from zope.component import queryAdapter class IAdaptsTo(Interface): def someMethod(): blah, blah. class DefaultImpl(object): # Note that we require no decorator or advice def __init__(self, context): self.context = context def someMethod(self): return 'whatever' def anotherClient(context, request): adapted = queryAdapter(context, IAdaptsTo) if adapted is None: adapted = DefaultImpl(context) # now use it (Note that memoization isn't a practical optimization doesn't work for adapters.) If we added a 'default_factory' argument to 'queryAdapter', we wouldn't need the 'if' statement, which would make this example as compact as the utility version. Or we could add a 'queryAdapterFactory' API instead, and have 'queryAdapter' use it (what is one more function call between friends? ;) The one downside I can see is giving up on the sugar^Wexpressivity of calling the interface directly -- I guess we could propagate the 'default_factory' argument through to the '__call__' of interface. Note that I *wanted* some extra sugar at one point (doing utility lookup when no arguments were passed to Interface.__call__), but I haven't missed that convenience much since I went on a low sugar diet with BFG / pyramid. I'd like to see us come up with a pythonic way to wire components up that can be overridden through registration (through zcml or otherwise). Ideally, the mechanism shouldn't feel like configuration but like programming. My example feels like programming to me: no ZCML, no decorators, and no advice needed up until the point you want to override the normal defaults. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2GND0ACgkQ+gerLs4ltQ6ynwCeJ1u/Bk3u8LGxhgR1jk2CFQP3 ZrcAoIuZbFCh2dpB611jKvOlUx48alqo =lvhO -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
- The mechanism shouldn't require something to grok/analyze the code. The mechanism should be explicit. This is implied by pythonic. I remember Grok being more implicit than skimming the links above suggest. Perhaps Grok has has become more explicit than I remember. +10^something from my point of view - from one kind of developer - grok doesn't make things easier. the implicitness of grok and it's magic black box behavior makes things harder to understand. that's something which should really be avoided for ZTK, if possible. configuration should be explicit. my 2 ¢ best, johannes raggam -- johannes raggam / thet python plone zope development http://johannes.raggam.co.at/ mailto:johan...@raggam.co.at http://bluedynamics.com/ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
