Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Tuesday, April 05, 2011, Lennart Regebro wrote: > On Tue, Apr 5, 2011 at 11:57, Lennart Regebro wrote: > > On Tue, Apr 5, 2011 at 07:56, Chris McDonough wrote: > >> Did this particular effort get to the place where there are students and > >> mentors lined up to do ZTK porting? > > > > No, it got to the pace where I'm supposed to set up a team page on a > > Wiki. > > Done: http://wiki.zope.org/gsoc/SummerOfCode2011 I added myself to the wiki, registered at the GSoC page and requested being a mentor for the PSF. 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 Tue, Apr 5, 2011 at 11:57, Lennart Regebro wrote: > On Tue, Apr 5, 2011 at 07:56, Chris McDonough wrote: >> Did this particular effort get to the place where there are students and >> mentors lined up to do ZTK porting? > > No, it got to the pace where I'm supposed to set up a team page on a Wiki. Done: http://wiki.zope.org/gsoc/SummerOfCode2011 ___ 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 Tue, Apr 5, 2011 at 07:56, Chris McDonough wrote: > On Thu, 2011-03-17 at 14:57 -0400, Lennart Regebro 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. They probably want to get more of the Zope Toolkit ported >> to Python 3. I forwarded the roadmap to him, so anyone who wants to >> mentor, that would be great. >> >> I've said I'm available to ask questions about porting and help from a >> technical point of view, but I suck at the mentoring part, so somebody >> else that does that is needed. >> >> Mail him at arcri...@gmail.com if interested. > > Did this particular effort get to the place where there are students and > mentors lined up to do ZTK porting? No, it got to the pace where I'm supposed to set up a team page on a Wiki. ___ 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, 2011-03-17 at 14:57 -0400, Lennart Regebro 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. They probably want to get more of the Zope Toolkit ported > to Python 3. I forwarded the roadmap to him, so anyone who wants to > mentor, that would be great. > > I've said I'm available to ask questions about porting and help from a > technical point of view, but I suck at the mentoring part, so somebody > else that does that is needed. > > Mail him at arcri...@gmail.com if interested. Did this particular effort get to the place where there are students and mentors lined up to do ZTK porting? - 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] Anyone want to do Google Summer of code mentoring for PSF?
Am 20.03.2011, 18:07 Uhr, schrieb Tres Seaver : > 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. Callable interfaces are, in my view, a huge wart with a pimple on top! Convenient, yes, but just try and explain why a specification against which "living" code should be built should itself be executable. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] 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?
On 03/20/2011 04:29 PM, Jim Fulton wrote: > On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichting 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?
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?
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/20/2011 02:31 PM, Jim Fulton wrote: > On Sat, Mar 19, 2011 at 5: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? > > 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?
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 Mon, Mar 21, 2011 at 13:28, Stephan Richter 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] 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 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 )
Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
On Sun, Mar 20, 2011 at 01:06, Stephan Richter 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: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 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?
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 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 AkkermanIt 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?
> - 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 )
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 Design"http://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?
On Sun, Mar 20, 2011 at 4:29 PM, Jim Fulton 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?
On Sun, Mar 20, 2011 at 4:31 PM, Martin Aspeli wrote: > 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. There's really no choice. The syntax we use today simply doesn't work in Python 3. We already have 2to3 fixers for zope.interface and zope.component, which will do the work for you and change things into decorators like: class Foo(object): implements(IFoo) ... @implementor(IFoo): class Foo(object): ... Any in-class advice construct will change. In cases where we use multiple statements per class (like implements + adapts), I think it's worthwhile to combine these into one higher-level construct. Registering a view should be done via some variation of a @view decorator and not by adding multiple low-level statements. 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?
Hi, On 20 March 2011 15:29, Jim Fulton 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?
Hi,
On 20 March 2011 15:00, Hanno Schlichting wrote:
> On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton 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?
On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichting wrote:
> On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton 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?
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 Fulton 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 3/20/11 16:00 , Hanno Schlichting wrote: > On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton 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 Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton 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 Sun, Mar 20, 2011 at 9:49 AM, Martin Aspeli wrote: > On 20 March 2011 13:46, Jim Fulton 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 20 March 2011 13:46, Jim Fulton 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 ? 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 Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro 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 Sat, Mar 19, 2011 at 5: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? 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 Sat, Mar 19, 2011 at 8:06 PM, Stephan Richter 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 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. 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?
Getting ZCA/ZTK to run on PyPy is probably easier, and actually more useful. Maybe someone would want to mentor that? On Thu, Mar 17, 2011 at 22:08, Jim Fulton wrote: > On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro 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. They probably want to get more of the Zope Toolkit ported >> to Python 3. I forwarded the roadmap to him, so anyone who wants to >> mentor, that would be great. > > I hope that isn't what they want. :) > > His stated goal for GSOC was to bring people into the community. I > can't think of many better ways to turn someone off than to ask them > to port something from Py2 to Py3. > > 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 13:07, Lennart Regebro wrote: > On Thu, Mar 17, 2011 at 22:08, Jim Fulton wrote: >> On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro 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. They probably want to get more of the Zope Toolkit ported >>> to Python 3. I forwarded the roadmap to him, so anyone who wants to >>> mentor, that would be great. >> >> I hope that isn't what they want. :) >> >> His stated goal for GSOC was to bring people into the community. I >> can't think of many better ways to turn someone off than to ask them >> to port something from Py2 to Py3. > > Well, that's what he said. But in any case it might be a good idea if > Zope people joined the PSF GSoC project to vote and comment on any > zope related applications if those show up. I will, even though I > refuse to be a mentor, since I suck at it. Ah, actually, this year you put together "teams". So in this case we need a Zope team. So if nobody shows interest we don't have a team, and we won't do anything. //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 Thu, Mar 17, 2011 at 22:08, Jim Fulton wrote: > On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro 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. They probably want to get more of the Zope Toolkit ported >> to Python 3. I forwarded the roadmap to him, so anyone who wants to >> mentor, that would be great. > > I hope that isn't what they want. :) > > His stated goal for GSOC was to bring people into the community. I > can't think of many better ways to turn someone off than to ask them > to port something from Py2 to Py3. Well, that's what he said. But in any case it might be a good idea if Zope people joined the PSF GSoC project to vote and comment on any zope related applications if those show up. I will, even though I refuse to be a mentor, since I suck at it. //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 Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro 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. They probably want to get more of the Zope Toolkit ported > to Python 3. I forwarded the roadmap to him, so anyone who wants to > mentor, that would be great. I hope that isn't what they want. :) His stated goal for GSOC was to bring people into the community. I can't think of many better ways to turn someone off than to ask them to port something from Py2 to Py3. 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 )
[Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?
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. They probably want to get more of the Zope Toolkit ported to Python 3. I forwarded the roadmap to him, so anyone who wants to mentor, that would be great. I've said I'm available to ask questions about porting and help from a technical point of view, but I suck at the mentoring part, so somebody else that does that is needed. Mail him at arcri...@gmail.com if interested. //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 )
