[Zope3-dev] Re: Zope 3 releases?
Stephan Richter <[EMAIL PROTECTED]> writes: >> - We need to decide what a Zope 3 release is (or maybe multiple >> flavors). I favor copying the linux experiences, but have an open >> mind. > > I like the Linux parallel as well. I think it would be nice, if we > treat the Zope 3 name like Debian, and Grok or other frameworks on > top of it like Knoppix or other Debian-derived distributions. There is danger here. Many in the industry consider Linux to be an absolute disaster - because after you develop an application on one distribution, you can spend months trying to support customers who attempt to run it on other distributions! In the wider Unix world things are even worse. Tools like "autoconf" absorb months and years of developer effort to simply get products to compile everywhere. I will suggest an alternative model: Python. The Zope project should not operate like Linux, but like Python. The magic of Python is that it comes with a Standard Library. I am sure, of course, that it takes the Python developers much more time to come out with each version of Python because they have to keep the Standard Library working; I am sure it is troublesome trying to get all the volunteer maintainers on board when they want the next release to meet its deadline; and it seems obvious that both Python and each Standard Library module could evolve faster on their own, without their releases tied to each other. But what an immense benefit results! The normal Python coder, who stands outside the development of the language itself, needs to only be told "this is Python 2.4", and knows automatically not only which core features the language will have, but, also, what versions of one hundred other packages he will be working with. Hearing "2.5" not only tells you that iterator comprehensions are available, but that "datetime" has finally grown a .strptime class method! Now, it sounds like Zope is about to stop being like Python and start being like the current Wild West of Linux distributions. If I want to write a WebWidget in the future, and want it to work with Grok, and Zope on Wheels, and ZopeSprockets, and whatever other frameworks might come along, then I will be faced with situations like "Well, Grok has already moved up to zope.security 3.7, which means I can use key cards natively! Hmm, but the other frameworks have not upgraded past 3.6; I will have to special-case key-cards for them. On the other hand, Grok stayed with zope.templates 3.5 because they piled so many extensions on top that they didn't get time to redevelop them for 3.6, so I'm going to have to fake push-masking in Grok..." In conclusion (and there's a dozen more arguments I want to make, but I think they're all pretty obvious if you start drawing more analogies like the ones above), I think that breaking Zope into eggs makes about as much sense as shipping Python bare and making users assemble working sets of the Standard Library out of Cheeseshop eggs. While perhaps saving a bit of time for the core developers, and perhaps letting new releases come a bit faster since they are not all linked together in a big release, the result of such a move will be to inflict a terrible cost on the normal developer, who will have to re-invent "autoconf" for Zope in order to have any hope of people using his WebWidget. While I'm being all contrary, I might as well make a whimsical suggestion, a small gedankenexperiment: what if we went beyond the suggestion that I am making here - which is that all "core" Zope 3 eggs continue to be released at the same time with a "big version number" attached, exactly like Python and its Standard Library are - and actually encouraged other tools and frameworks to "join in" and follow the same cycle? What, in other words, if there were some way for the WebWidget author - who, you will recall, wants people using all sorts of Zope-based frameworks to be able to use his product - to package his product such that you got the "right version" for the version of Zope you were using? So that someone who put "webwidget" in their "install_requires" stanza would get the "3.4" version if they were using "Zope 3.4", and "3.5" if their Zope version was "3.5", and so forth? Then, not only would all of the Zope core packages be evolving in lockstep, but third-party tools could voluntarily "follow along" with the release cycle schedule, and be able to guarantee that things kept working smoothly for their users. It would be like having to grab the Python-LDAP that claims to work with the Python version you're working with, but where the selection was made automatically without your having to think about it. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: reasonable syntax for multi-adaptation
Tres Seaver <[EMAIL PROTECTED]> writes: > Martijn Faassen wrote: > >> IFoo.adapt() for normal adaptation >> IFoo.multiadapt() for multi adaptation > > I'd rather have 'adapt' take *args for the contexts, and keywords > for extras (like name). And you could make the "default=" another possible extra! In which case our proposals at the moment compare something like this: Brandon Utility? IFoo() Single adaptation IFoo(a) ... with default IFoo(a, default=y) Multi adaptation IFoo(multi=(a,b)) ... with default IFoo(multi=(a,b), default=y) Named multi adapter IFoo(multi=(a,b), name='z') ... with default IFoo(multi=(a,b), name='z', default=y) Martijn/Tres Utility IFoo.adapt() Single adaptation IFoo.adapt(a) ... with default IFoo.adapt(a, default=y) Multi adaptation IFoo.adapt(a,b) ... with default IFoo.adapt(a,b, default=y) Named multi adapter IFoo.adapt(a,b, name='z') ... with default IFoo.adapt(a,b, name='z', default=y) Well, I have to admit, yours are a lot prettier. The word "adapt" takes no more characters than my "multi", and parenthesis disappear! And though I might quibble that "adapt()" would be better spelled "utility()", there is a nice symmetry about your idea. - Both patterns make it explicit to anyone reading the code when a default value is being passed, which should vastly reduce surprise. - Mine feels more natural and Pythonic to people who, like PvW in his book, think of adaptation as being like casting. - On the other hand, adaptation is *not* casting, and having to spell out "adapt" really makes for explicit code! And the very natural handling of single or multiple *args in your scheme is very pretty. - My scheme requires the coder to remember that multi-adaption is "done differently" than normal adaption; yours does not. - My scheme, by requiring the magic keyword "multi=", leaves the user in the same dratted danger as before - that he will call IFoo(a, b) and think that he's multiply adapting! Given those last two points, I must abandon my earlier proposal and respond to that of Martijn and Tres with: +1 -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: reasonable syntax for multi-adaptation
Jim Fulton <[EMAIL PROTECTED]> writes: > On Sep 26, 2007, at 10:04 AM, Brandon Craig Rhodes wrote: > >> Instead, multi-adaption should look like this: >> >> IFoo(multi=(obj1, obj2)) >> IFoo(multi=(obj1, obj2), name='site_foo') > > Ah, using keyword arguments to get around limitations (especially > backward compatibility issues) with the current API is a neat idea. > If we were going to do this though, I think a method syntax would be > cleaner. As in: > > IFoo.adapt([ob1, ob2], 'site_foo', None) -1. Unfortunately the singular verb "adapt" makes it look like normal adaptation is what is being called for - it looks here like you are trying to adapt a list to the IFoo interface. Maybe ".multiadapt()"? > Note that IFoo(ob) has some special semantics that don't apply to > the multi- or named-adapter case. Agreed! The semantics are different. But mightn't we simply document this difference between single- and multi-adaptation everywhere we need to, rather than letting it force us into splitting the adapter syntax into two unwieldy pieces? I would not imagine that I would be confused encountering documenting that said: Call IFoo(x) to adapt a single object "x" to the IFoo interface, and IBar(multi=(x,y)) to have the adapter registry find and invoke a multi-adapter that adapts the pair of objects "x" and "y" to the IBar interface. When performing single adaptation, the object "x" itself is simply returned if it already offers the IFoo interface; and if the object offers a __conform__ method, then this is called with the IFoo interface as its argument in place of the normal adaptation machinery. So, I am not sure that I see yet the problem with "mixing APIs". For me, the essential issue is that in both single- and multi- adaptation you are returned an instance of an adapter that has been instantiated with the objects you are adapting. Both of these syntaxes: IFoo(x) IBar(multi=(x,y)) suggest this fact, even to the novice Python programmer, because they make it look like something is being instantiated with the arguments given, and returned. Doesn't the benefit of such clarity and symmetry outweigh whatever slight awkwardness might exist in the sort of documentation I suggested above? > An added complication is that interfaces don't provide adaption > directly, but via a hook. The existing hook api wouldn't work for > mult or named adaptation, so a new hook would be needed. I had assumed that IBar(multi=(obj1, obj2)) would simply dispatch to the existing getMultiAdapter() call; how, exactly, would hooks get involved and complicate things? Feel free to just cite a line number and tell me to go read, all I need is a pointer to get started understanding this. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] reasonable syntax for multi-adaptation
The current syntax for multi-adaptation makes the interface look like an object of the adaptation, rather than the actor in the operation. Instead, multi-adaption should look like this: IFoo(multi=(obj1, obj2)) or: IFoo(multi=(obj1, obj2), name='site_foo') The first draft of such an implementation could simply intercept a "multi" keyword passed to InterfaceBasePy.__call__(), and hand control over to the traditional getMultiAdapter. The old getMultiAdapter call should always remain available, but code will become much easier to read as the new syntax is adopted and single- and multi-adaptation become visually congruent. I'll be happy to develop a patch and test cases. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
