Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On 2011-3-20 17:47, Hanno Schlichting wrote: 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. Pyramid's config.include sounds like exactly that. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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, Not sure where to 'hook into' the discussion thread, so I'll just start here: On 3/20/11 15:28 PM, Jim Fulton wrote: 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. Do you mean without having a configure.zcml trigger the scanning (a.k.a. grokking) process? Or do you mean, a mechanism that doesn't use configuration actions from zope.configuration? If there's a different way to trigger the scanning process, that would be mostly fine for Grok. There's a couple of things actually configured thru ZCML files in some of the grokcore.* packages. I think they could be rewritten if necessary. ZCML files are as far as I can see not essential to Grok - they are surely not essential to martian (the scanning/grokking library used). - 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 have the feeling the explicit versus implicit part of the discussion has been somewhat mixed with the to scan or not to scan part of the discussion. Nothing in the martian library dictates implicitness as far as I can see. How Grok uses martian though, does have implicit, conventions-over-configuration design choices. Actually, these conventions-over-configuration choices are regularly discussed within the Grok community - some people (including myself) would like to see Grok not doing any guessing of configuration parameters during the grokking-phase of the application at all. Others disagree. As an example, there's the megrok.strictrequire package that, when included in a grok-based application, will raise grok errors when there are view components without an explicitly set permission requirement (where Grok normally would have used a conventional value). - I'd prefer not to rely on subclassing, but I'm not dead set against it. For most components Grok relies on subclassing indeed. Note that registering global utilities, for example, can be done using module-level directives too, like can be done for adapters and subscriptions. - 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) Just to be sure: this is what is called advice based syntax or in-class advice right? Grok people call this a directive. Anyway, as apparently this wouldn't work in Python 3 anymore, Grok should come up with an alternate spelling. Actually, people have already suggested to start using class decorators instead of in-class directives. Personally, I do not see an essential cosmetic difference between using a class decorator or a in-class directive. Like was said earlier in the thread: Grok had to use directives since there were no class decorators at that time. And what I have seen of Pyramid and venusian, the grok directives do mostly what the class decorators do: they leave information on the class in one way or another, that later is picked up in the scanning/grokking phase and used for registrations. Grok uses grokkers for that - meta-components that know how they can use the information left by the directives for making registrations (thru the zope.configuration configuration actions mechanism, which as a result plays nice with existing pure zcml registrations) What I know of venusian/Pyramid, is that the class decorators leave callbacks that will do the registrations in the scanning phase. Right? 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. I do not think the Grok project would be principally against this. regards, jw ___ 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:12 PM, Wichert Akkerman wrote: 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. Just to get this clear for me: if you're not scanning, the information left by the class decorators would be inert? So, you'd have to do the registrations yourself, right? 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). Martian skips tests by default. You can tell it, at least to a certain extend, what to scan and what not to scan. - 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. This is true. - scanning can take a long time, making application (re)start slow for non-trivial projects At what point is an application not trivial anymore? In applications I build so far, startup time has not been an issue at all. But maybe my applications are still on the trivial-end of the spectrum ;) - 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. I think this can be true. In my experience not relying on implicitly or guessed configuration parameters helps a little here. What in this specific example was the reason for the view not being picked up? regards, jw ___ 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/21/11 10:17 , Jan-Wijbrand Kolman wrote: On 3/20/11 16:12 PM, Wichert Akkerman wrote: 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. Just to get this clear for me: if you're not scanning, the information left by the class decorators would be inert? So, you'd have to do the registrations yourself, right? Yes. - 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. This is true. I ran into this with .html.py files generated by Chameleon as well. My Zope startup has lots of these: /Users/wichert/Library/eggs/zope.configuration-3.6.0-py2.6.egg/zope/configuration/config.py:605: UserWarning: File 'sessions.pt.pyc' has an unrecognized extension in directory '/Users/wichert/Work/syslab/euphorie/Develop/trunk/buildout/src/Euphorie/euphorie/client/templates' - scanning can take a long time, making application (re)start slow for non-trivial projects At what point is an application not trivial anymore? In applications I build so far, startup time has not been an issue at all. But maybe my applications are still on the trivial-end of the spectrum ;) If your application takes 5 seconds to start I'ld call it non-trivial :) - 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. I think this can be true. In my experience not relying on implicitly or guessed configuration parameters helps a little here. What in this specific example was the reason for the view not being picked up? A missing zcml include for meta.zcml of plone.directives.form, while it's configure.zcml was included correctly. 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 01:06, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Saturday, March 19, 2011, Lennart Regebro wrote: Getting ZCA/ZTK to run on PyPy is probably easier, and actually more useful. Maybe someone would want to mentor that? While I would mentor someone wanting to do such a project, I would be much more interested in seeing a working WebOb to zope.publisher bridge. I know Jim(?) 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. So I'll sign up as a Zope team member. Cool. But it turns out we need three to make a team (see https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUUVGWmc6MQ), and we only really have one. :-) I guess I could take a bullet for the team too, but that still makes only two. Maybe next year. :-) //Lennart ___ 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/21/11 10:30 AM, Wichert Akkerman wrote: - 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. This is true. I ran into this with .html.py files generated by Chameleon as well. My Zope startup has lots of these: /Users/wichert/Library/eggs/zope.configuration-3.6.0-py2.6.egg/zope/configuration/config.py:605: UserWarning: File 'sessions.pt.pyc' has an unrecognized extension in directory '/Users/wichert/Work/syslab/euphorie/Develop/trunk/buildout/src/Euphorie/euphorie/client/templates' I think this particular warning is not due to the scanning process itself, but due to the way Grok tries to associate templates to views. It is still true though that the .pt.py files generated by chameleon will be scanned anyway. regards, jw ___ 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 )
[Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
I haven't read through the whole discussion in detail, so I'm sure I repeat some of what has been said already, but here is my point of view. 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of taste, but much of the implicitness makes sense. You typically do have a model and a view and a template, and the model and view are typically in one module, and has a name similar to the template. That implicitness however only makes sense in the specific context of web applications. There is no reasonably way to have that implicitness with components and adapters. So a configuration for the ZCA in general can't be implicit. 2. That doesn't mean we can't use grok-style configuration though. 3. Although Python 3 means we can't. We'll have to use decorators. 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Also, the decorators will always return the original component, meaning they can easily be used as post-config: @adapter(IMyFace, IMyFeet) class FootInMouth(object): ... Will mark the class as an adapter, but not register it. @adapt(IMyFace, IMyFeet) class FootInMouth(object): ... Will mark and register. @adapter(IMyFace, IMyFeet) class FootInMouht(object): ... adapt(FootInMouth)() Will register a previously marked adapter, and adapt(FootInMouth)(IMyFace, IMyFeet) Will mark and register. This means you can, if you want, still have the interfaces in one file, the implementations in one file, and the registrations separately (say, configure.py), thereby getting the same separation as you had with interfaces.py, components.py and configure.zcml. Your package just needs to *not* import the configure.py file. On Mon, Mar 21, 2011 at 12:47, Lennart Regebro rege...@gmail.com wrote: I haven't read through the whole discussion in detail, so I'm sure I repeat some of what has been said already, but here is my point of view. 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of taste, but much of the implicitness makes sense. You typically do have a model and a view and a template, and the model and view are typically in one module, and has a name similar to the template. That implicitness however only makes sense in the specific context of web applications. There is no reasonably way to have that implicitness with components and adapters. So a configuration for the ZCA in general can't be implicit. 2. That doesn't mean we can't use grok-style configuration though. 3. Although Python 3 means we can't. We'll have to use decorators. 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. //Lennart ___ 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 ) ___ 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 )
[Zope-dev] Zope Tests: 68 OK, 34 Failed, 6 Unknown
Summary of messages to the zope-tests list. Period Sun Mar 20 12:00:00 2011 UTC to Mon Mar 21 12:00:00 2011 UTC. There were 108 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 29 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 59 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:44:36 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035632.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:44:59 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035633.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:46:37 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035634.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:57:26 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035639.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 10:12:01 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035645.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 13:05:48 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035646.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 13:10:43 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035649.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 13:12:19 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035650.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:21:50 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035658.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:26:33 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035661.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:28:05 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035662.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:41:43 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035665.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:43:55 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035666.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:48:55 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035668.html Subject: FAILED : winbot / zc_buildout_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sun Mar 20 17:07:28 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035690.html Subject: FAILED : winbot / zc_buildout_dev py_265_win32 From: buildbot at winbot.zope.org Date: Sun Mar 20 17:07:39 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035691.html Subject: FAILED : winbot / zc_buildout_dev py_265_win64 From: buildbot at winbot.zope.org Date: Sun Mar 20 17:07:50 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035692.html Subject: FAILED : winbot / zc_buildout_dev py_270_win32 From: buildbot at winbot.zope.org Date: Sun Mar 20 17:08:00 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035693.html Subject: FAILED : winbot / zc_buildout_dev py_270_win64 From: buildbot at winbot.zope.org Date: Sun Mar 20 17:08:14 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035694.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Sun Mar 20 18:03:41 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035696.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Sun Mar 20 18:10:54 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035699.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-osx From: jdriessen at thehealthagency.com Date: Sun Mar 20 18:13:14 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035700.html Subject: FAILED : winbot / z3c.ptcompat_py_265_32 From: buildbot at winbot.zope.org Date: Sun Mar 20 20:04:06 EDT 2011 URL:
Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 7:47 AM, Lennart Regebro rege...@gmail.com wrote: ... 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. I'm not going to comment any more on the broader thread unless/until I have something specific to propose. Having said that, I'd like to go on record as wanting to review the zca port to Python 3 before it's finalized. 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 Monday, March 21, 2011, Lennart Regebro wrote: So I'll sign up as a Zope team member. Cool. But it turns out we need three to make a team (see https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUU VGWmc6MQ), and we only really have one. :-) I guess I could take a bullet for the team too, but that still makes only two. Maybe next year. :-) Jim said he would be willing to mentor someone for the right project. That would make us three. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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 Mon, Mar 21, 2011 at 13:28, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday, March 21, 2011, Lennart Regebro wrote: So I'll sign up as a Zope team member. Cool. But it turns out we need three to make a team (see https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUU VGWmc6MQ), and we only really have one. :-) I guess I could take a bullet for the team too, but that still makes only two. Maybe next year. :-) Jim said he would be willing to mentor someone for the right project. That would make us three. Ah, OK. I'll sign up then. ___ 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] Zope Tests: 68 OK, 34 Failed, 6 Unknown
2011/3/21 Zope Tests Summarizer zope-te...@epy.co.at: Summary of messages to the zope-tests list. Period Sun Mar 20 12:00:00 2011 UTC to Mon Mar 21 12:00:00 2011 UTC. There were 108 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 29 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 59 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:44:36 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035632.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:44:59 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035633.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:46:37 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035634.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:57:26 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035639.html Subject: FAILED : Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 10:12:01 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035645.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 13:05:48 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035646.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 13:10:43 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035649.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Sun Mar 20 13:12:19 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035650.html Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:21:50 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035658.html Subject: FAILED : Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:26:33 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035661.html Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:28:05 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035662.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:41:43 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035665.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:43:55 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035666.html All of Zope2 test failures that I have looked at have been caused by r121036 http://zope3.pov.lt/trac/changeset/121036/Zope/trunk/src/ZServer that adds support for IPv6 to ZServer. It should work with ZConfig trunk, that also adds IPv6 support, but has not been released http://zope3.pov.lt/trac/changeset/116987/ZConfig/trunk Please release ZConfig or unpin 2.8.0 from Zope trunk. Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:48:55 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035668.html Many other failures were connection problems. -- Gediminas ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Hi there, For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. I'm not sure what Lennart means by point 1. Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. The only implicit behavior left would be the grokking process, which generally recognizes subclasses of particular base classes as something to register. You could do away with this using class decorators as well, but that would require some changes to Martian to allow it to recognize things that way. (and it won't work for grokking instances, just classes and functions) Note that Pyramid as far as I understand also has a non-ZCML configuration method that is closer to ZCML. Regards, Martijn ___ 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 03/19/2011 10:02 PM, Lennart Regebro wrote: Getting ZCA/ZTK to run on PyPy is probably easier, and actually more useful. Maybe someone would want to mentor that? I agree it'd be easier and more useful. There's also interesting potential in exploiting PyPy's magic in things like security and ZODB persistence. Regards, Martijn ___ 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 03/20/2011 02:31 PM, Jim Fulton wrote: On Sat, Mar 19, 2011 at 5:02 PM, Lennart Regebrorege...@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.) That's true, we had bad experience with the Jython project a few years ago. It depends on the students though; I think we had better experience with a project to move Zope 2 forward to a newer version of Python 2.x (if I recall that correctly). But writing new code is a lot more fun. But if you're going to do porting, PyPy is a lot more tempting as a target for me. Regards, Martijn ___ 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 03/20/2011 03:28 PM, Jim Fulton wrote: Hm, it's been a while since I've looked at grok. Some notes: We have more than four years of experience with this topic... - The mechanism I'm thinking of should not require *any* ZCML. Check. we just bootstrap the grokking process from ZCML right now. We use zope.configuration actions to be compatible with 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. The basic principles are still the same. We still import code and grok those classes/instances/functions we want to do something with. Now that we have class decorators we could come up with another collection mechanism however. That said, you'd still need to import the modules at some point, otherwise collection will not take place as the decorators don't get executed in the first place. Martian has been expanded a lot though. I recommend looking at Martian. - I'd prefer not to rely on subclassing, but I'm not dead set against it. Class decorators might work. Subclassing does have some nice properties though; it feels Python and it becomes easy to come up with your own domain specific base classes. But it's not a major gain over class decorators I imagine. Note that if you do directives on classes at all, you're going to have to think about how subclassing interacts with configuration. 'implements' is a good example of that. - 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. Yeah, a nice project would be to let Grok use class decorators instead of old style traceback-exploiting class directives. We have a fairly well defined directive mechanism which knows about inheritance. It even knows about module-level directives that affect all classes in the module and then those classes have subclasses. 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. I'm not sure how the behavior would be affected based on experience. For 'implements' for example, we still want subclassing behavior, don't we, decorator or not. Regards, Martijn ___ 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 03/21/2011 10:17 AM, Jan-Wijbrand Kolman wrote: - scanning can take a long time, making application (re)start slow for non-trivial projects At what point is an application not trivial anymore? In applications I build so far, startup time has not been an issue at all. But maybe my applications are still on the trivial-end of the spectrum ;) In general we haven't really gotten much feedback about this being a performance issue, as far as I know. The modules need to be imported at some point anyway so we don't really add much overhead there, and otherwise it's just going through the module's attributes, which I imagine comes down to looping through a dictionary really and doing a lot of isinstance and issubclass calls. That's going to be pretty fast. It might even be faster than ZCML XML parsing, it's hard to say. :) Regards, Martijn ___ 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 03/20/2011 04:29 PM, Jim Fulton wrote: On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichtingha...@hannosch.eu wrote: [snip] 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. You might have a module that you don't import at all, but does define components you want to be wired up. How is this module going to be registered? You could import it after all in some module you *know* is going to be imported (which one?). It seems rather easy to make a mistake here and wonder why things don't get configured. Plus you're importing stuff that you then don't use. Second, well, really, I'm not ready to give up on a straightforward definition of wiring that doesn't rely on module scanning. You could do the wiring using class decorator side effects, but the module will still need to be touched to get the decorators to kick in. Regards, Martijn ___ 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 there,
On 03/20/2011 04:00 PM, Hanno Schlichting wrote:
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
It's interesting to consider inheritance rules here. What if you
subclass from HelloWorldTranslationDomain? What happens to name and the
interface that the utility is provided under?
I'm not saying I know the right rules for inheritance in all cases, or
that grokcore.component is sane here, but I know in some cases having
directive values inherit is pretty neat, and in some cases it isn't. I
imagine registration can always be explicit, however.
Note also that if we're simply talking spelling, this makes grok a bit
shorter and is the way Grok code typically looks:
import grokcore.component as grok
from zope.i18n.interfaces import ITranslationDomain
class HelloWorldTranslationDomain(grok.GlobalUtility):
grok.implements(ITranslationDomain)
grok.name('helloworld')
Regards,
Martijn
___
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 there, On 03/20/2011 05:47 PM, Hanno Schlichting wrote: 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. I don't understand. Venusian took its ideas from Martian, and Martian's not a web framework and never has been. http://pypi.python.org/pypi/martian Surely you've heard of this library before? Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 14:17, Martijn Faassen faas...@startifact.com wrote: Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. Sure, but I'm of course referring to how it behaves by default, including the associations made by the grokking process. I think that makes sense in a webapp, but not otherwise, and we should at least as a start concentrate on the generic component architecture case. For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. And the same goes for zope.component support, of course. With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 10:07 AM, Lennart Regebro rege...@gmail.com wrote: On Mon, Mar 21, 2011 at 14:17, Martijn Faassen faas...@startifact.com wrote: ... With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. I think Martijn raised a good question about the conceptual interaction of class decorators and inheritance. (Arguablly the questions applies to the advice-based syntax as well.) If I see: @some_decorator class Base: class Sub(Base): ... I'm going to wonder how the decorator affects Sub. (Wondering is work. :) This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Maybe it's enough to document what the directives do. Or maybe something less attached to the class definition would make sense. I don't know what the right answer is ... at least not yet. :) 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 03:07 PM, Lennart Regebro wrote: On Mon, Mar 21, 2011 at 14:17, Martijn Faassenfaas...@startifact.com wrote: Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. Sure, but I'm of course referring to how it behaves by default, including the associations made by the grokking process. I think that makes sense in a webapp, but not otherwise, and we should at least as a start concentrate on the generic component architecture case. For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. And the same goes for zope.component support, of course. We have a much more extensive directive abstraction though. That should make it harder and easier at the same time. :) With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. Do we really care about the Python world in general? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. You'll still need a module importing process, as I sketched out elsewhere, if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Note that we do support function decorators with Martian. Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 03:28 PM, Jim Fulton wrote: I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Of course metaclasses are not very good for this as they're surprising in other ways and use unstructured configuration happening at import time. Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 15:28, Jim Fulton j...@zope.com wrote: This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Well, the wonkyness comes from @utility *not* being inherited, while @implements would be. That could be confusing. It wold be possible to let @utility be inherited if it's done by scanning, though. But under what name in that case? I think that possibly would be even *more* confusing. It may be that decorators isn't the right answer for registration. In that case scanning is an option, unless we simply go for straight imperative configuration. @implementer(IMyFace) @adapter(IMyFoot) class FootInFace(object): def __init__(self, foot, face) self.foot = foot self.face = face component.utility(FootInFace()) It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. On Mon, Mar 21, 2011 at 15:36, Martijn Faassen faas...@startifact.com wrote: Do we really care about the Python world in general? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. Yeah, but that's to a large extent because class decorators still are relatively new. You can't use them if you need to support Python 2.5. You'll still need a module importing process, as I sketched out elsewhere if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Is that a problem? In the end, no matter what you do, the module needs to be imported. :-) That a utility doesn't get registered unless you import a specific module somewhere in the app doesn't seem like a problem to me. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen faas...@startifact.com wrote: On 03/21/2011 03:28 PM, Jim Fulton wrote: I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Ick. Of course metaclasses are not very good for this as they're surprising in other ways Agreed. 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 04:08 PM, Jim Fulton wrote: On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen faas...@startifact.com wrote: On 03/21/2011 03:28 PM, Jim Fulton wrote: I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Ick. Of course metaclasses are not very good for this as they're surprising in other ways Agreed. Martian allows you to use a similar spelling to metaclasses (base classes), without the weird surprises during run-time (after configuration is already done), and without significant import-time side-effects. With megrok.rdb I actually use SQLAlchemy declarative without their declarative metaclass, as the SQLAlchemy folks were kind enough to tweak their config code so I could call it directly from a grokker. Regards, Martijn ___ 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 )
[Zope-dev] We need to get the board green
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Too many never-resolve failures in our buildbots makes their output just noise: the amount of effort required to diagnose the cause of a failure seems to have no payoff if we don't get them each cleared up. I'm just about done with trying to diagnose them, myself, which is making me sad, as I *want* to be pleased with the quality of the software our community produces. 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/ iEYEARECAAYFAk2HdRQACgkQ+gerLs4ltQ6zMQCgt2V6zhx/zKRJBmI3KSw5qD75 OgsAoJYLAmLGSMd9p+ZbrMqjZwDk99UU =l0kU -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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: On Mon, Mar 21, 2011 at 15:28, Jim Fulton j...@zope.com wrote: This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Well, the wonkyness comes from @utility *not* being inherited, while @implements would be. That could be confusing. It wold be possible to let @utility be inherited if it's done by scanning, though. But under what name in that case? I think that possibly would be even *more* confusing. It may be that decorators isn't the right answer for registration. In that case scanning is an option, unless we simply go for straight imperative configuration. @implementer(IMyFace) @adapter(IMyFoot) class FootInFace(object): def __init__(self, foot, face) self.foot = foot self.face = face component.utility(FootInFace()) It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. - C ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 10:59 AM, Chris McDonough wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. +1. Pyramid has proven (IMHO) that a component registry can be friendly to developers without being global. Shane ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, 2011-03-21 at 14:13 -0400, Jim Fulton wrote: On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. I personally don't see the benefit of externalizing default configuration over having defaults be part of the call-site code as per Tres' example. Having the defaults in the code itself makes it much, much easier for people reading the code to understand the garden path. - C ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2011 02:13 PM, Jim Fulton wrote: On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. FWIW, I just added 'queryAdapterFactory' and 'queryMultiAdapterFactory' APIs to zope.component on a branch: http://svn.zope.org/zope.component/branches/tseaver-queryAdapterFactory/ These APIs make the almost never overridden / dependency injection case as compact for adapters as for utilities. 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/ iEYEARECAAYFAk2HqCYACgkQ+gerLs4ltQ7PFQCgnyoPFi8u8joVkA6wwDEL1ff0 IAcAn1l0s48CLGzVDRsF8tW32If7HCRm =WoQO -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] Zope Tests: 68 OK, 34 Failed, 6 Unknown
On Mon, Mar 21, 2011 at 4:53 PM, Tres Seaver tsea...@palladion.com wrote: On 03/21/2011 07:57 AM, Zope Tests Summarizer wrote: Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Sun Mar 20 09:46:37 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035634.html These all fail due to something like: Error in test test_escape (pythongettext.tests.test_compile.TestWriter) Traceback (most recent call last): File /home/zope/.buildout/eggs/unittest2-0.5.1-py2.6.egg/unittest2/case.py, line 340, in run testMethod() File /home/zope/.buildout/eggs/python_gettext-1.1-py2.6.egg/pythongettext/tests/test_compile.py, line 65, in test_escape po_file = file(os.path.join(self.folder, 'test_escape.po'), 'rb') IOError: [Errno 2] No such file or directory: '/home/zope/.buildout/eggs/python_gettext-1.1-py2.6.egg/pythongettext/tests/test_escape.po' and a bunch more in python_gettest-1.1. Why are we wedging in that library version if its tests are broken? Hhm, weird. The tests all passed for me locally. I made some changes and put in a 1.1.1. Let's see if the bots like that one. Subject: FAILED : Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:28:05 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035662.html The 2.14 failures are the ones Gedminas diagnosed, due to IPv6 syntax in the config file, not supported by ZConfig. I asked fdrake to make a new ZConfig release to get the IPv6 support into a released version. Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Sun Mar 20 15:43:55 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035666.html These are both weird Windows build failures:: error: Setup script exited with error: Unable to find vcvarsall.bat While: Installing test. Getting distribution for 'Acquisition==2.13.7'. Error: Couldn't install: Acquisition 2.13.7 This looks like the Windows bot downloaded the Acquisition tarball before the binary egg had been built. Someone needs to remove the tarball from the download cache, so setuptools downloads the eggs instead. 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 )
