Re: [Zope-dev] implementing zope.component 4.0

2009-12-05 Thread Adam GROSZER
Hi Jim, Do I remember well that you did the last optimization round around adapters? If yes, did you have some tests for that, they could be handy now. Saturday, November 28, 2009, 12:14:42 PM, you wrote: MF Adam GROSZER wrote: I had a feeling that adapter lookup can be alone slowish with lots

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Fred Drake
On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze t...@gocept.com wrote: To be honest, I just don't see why this whole singleton business shouldn't be orthogonal to the concepts of the component architecture. Well said. If an application cares about singleton creation or ownership of

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Gary Poster
On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze t...@gocept.com wrote: To be honest, I just don't see why this whole singleton business shouldn't be orthogonal to the concepts of the component architecture. Well said. If an application cares

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Thomas Lotze
Gary Poster wrote: On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze t...@gocept.com wrote: To be honest, I just don't see why this whole singleton business shouldn't be orthogonal to the concepts of the component architecture. Well said. If an

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Fred Drake
On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster gary.pos...@gmail.com wrote: You are arguing for the unification of utilities and adapters? No. I'm arguing not to conflate utilities with the singleton pattern or adaptation with ownership of the resulting adaptation. -Fred -- Fred L. Drake,

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Thomas Lotze
Martijn Faassen wrote: * a utility never has a connection. That's because it already got instantiated long before the lookup takes place. Isn't it the other way around: A utility never has a connection to any adapted object, and that's *why we can* instantiate it long before the lookup takes

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Chris McDonough
Thomas Lotze wrote: Martijn Faassen wrote: * a utility never has a connection. That's because it already got instantiated long before the lookup takes place. Isn't it the other way around: A utility never has a connection to any adapted object, and that's *why we can* instantiate it long

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Gary Poster
On Dec 2, 2009, at 8:58 AM, Fred Drake wrote: On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster gary.pos...@gmail.com wrote: You are arguing for the unification of utilities and adapters? No. I'm arguing not to conflate utilities with the singleton pattern or adaptation with ownership of the

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Thomas Lotze
Gary Poster wrote: Without this distinction, AFAICT either you want to conflate the ideas, or you have a concept of the differences between the two that is more esoteric than I think is useful. I get the impression that it is on the second point of those that we disagree. Right, I

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Lennart Regebro
Unifying adapters and utilities gets us nowhere. If we remove the distinction between an adapter and a utility we are simply left with the concept of component. Then we have components, nothing else. Components are objects registered base on what interface they implement, and can be looked up

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Stephan Richter
On Wednesday 02 December 2009, Lennart Regebro wrote: When there is such a clear and distinct conceptual difference between adapters and utilities, why would we try to murk that distinction by pretending that non adapters are a special case of adapters, when it's obvious that that's exactly

Re: [Zope-dev] implementing zope.component 4.0

2009-12-02 Thread Martin Aspeli
Chris McDonough wrote: Thomas Lotze wrote: Martijn Faassen wrote: * a utility never has a connection. That's because it already got instantiated long before the lookup takes place. Isn't it the other way around: A utility never has a connection to any adapted object, and that's *why we can*

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Hermann Himmelbauer
Am Montag 30 November 2009 16:57:11 schrieb Gary Poster: 1) The term adapter is a barrier to understandability, in my interviews. This is particularly the case when people are introduced to the idea of multiadapter and supscription adapter. In what ways are these anything like a type cast?

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martijn Faassen
Shane Hathaway wrote: [a lookup method instead of calling the interface] What do you think? Two objections to a method lookup: * I do like the notion of casting an object with an interface. We can at least interpret single adaptation that way. * doing a call better makes this lookup mechanism

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martijn Faassen
Gary Poster wrote: Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt a plug (required interface) so it can plugged in to

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martijn Faassen
Chris McDonough wrote: Tres Seaver wrote: [snip] The root of the disagreement here is that you seem to want the *caller* to care about something which is important only to the person who *registers* the thing being looked up. From the caller's perspective, the call site needs an object

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martin Aspeli
Martijn Faassen wrote: I don't like the word singleton very much either. Singleton in the Design Patterns book has a very particular implementation that is criticized by a lot of developers and in particular that particular pattern is very uncommon in the Python world (people just use

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Joachim König
Martin Aspeli wrote: For the record, I normally use the singleton analogy to explain unnamed global utilities. Perhaps that's bad, though I find it works pretty well. It'd probably be more accurate to use the terms you did, an extension of the singleton principle, but as you say, it just

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Hanno Schlichting
On Tue, Dec 1, 2009 at 3:38 PM, Martin Aspeli optilude+li...@gmail.com wrote: I'm certainly -1 on using the term in the ZCA. I think changing our nomenclature would be terrible for the same reasons I think changing (as opposed to extending/improving) our API would be terrible. Utilities are in

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martijn Faassen
Joachim König wrote: [snip] To me the fact that an object is a singleton or a factory is orthogonal to the registry stuff. Why can't utilities be factories too that simply return themselves when being called? Then being a singleton or not would be in the responsibility of the registered

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martin Aspeli
Martijn Faassen wrote: Joachim König wrote: [snip] To me the fact that an object is a singleton or a factory is orthogonal to the registry stuff. Why can't utilities be factories too that simply return themselves when being called? Then being a singleton or not would be in the

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Joachim König
Martin Aspeli wrote: Clearly, it could. But that's not the way we went. Changing it now would be really damaging, and I'm not sure what would be gained. I can imagine use cases where getting a new instance each time would be useful. But that is under the full controll of the __call__ of the

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Martin Aspeli
Joachim König wrote: Martin Aspeli wrote: Clearly, it could. But that's not the way we went. Changing it now would be really damaging, and I'm not sure what would be gained. I can imagine use cases where getting a new instance each time would be useful. But that is under the full controll

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Fred Drake
On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli optilude+li...@gmail.com wrote: I think that logically, these are two different concepts that meet two different sets of use cases. Agreed here. This is essential to this discussion. I've been quite surprised that there are so many who argue to

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Godefroid Chapelle
Fred Drake wrote: On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli optilude+li...@gmail.com wrote: I think that logically, these are two different concepts that meet two different sets of use cases. Agreed here. This is essential to this discussion. I've been quite surprised that there

Re: [Zope-dev] implementing zope.component 4.0

2009-12-01 Thread Thomas Lotze
Chris McDonough wrote: Furthermore he'll believe he owns the resulting object, because normal classes are always constructors that create a new object. Except when they don't. Apart from cases like short strings and small integers where Python itself doesn't create objects more than once, you

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Charlie Clark wrote: [snip] So adapters are reduced to type conversion? Adaptation is give me something that provides this API for this object. Conversion in Python asks the same. Adaption just formalizes this and generalizes it. I don't see how it's a reduction. Calling an interface is

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Chris McDonough wrote: Lennart Regebro wrote: I have very much come to appreciate the power of this delegation in, say, BrowserViews; even if it did take me several months to understand the multiadapter pattern! I hear this a lot, so this is apparently something that is common to take a

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Martin Aspeli wrote: Martijn Faassen wrote: Multi-adaptation: IFoo(one, two) Please note that this will break an incredible amount of code in the wild. A good number of my packages do something like this: foo = IFoo(context, None) if foo is None: ... Yes, that this

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Wolfgang Schnerring wrote: * Martijn Faassen faas...@startifact.com [2009-11-27 12:32]: Would people be okay with such an upgrade path? Any better ideas? Yes, I'm okay with it. I do think we should take care that the transition period is long enough, so that people have a chance to update

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martin Aspeli
Martijn Faassen wrote: Martin Aspeli wrote: Martijn Faassen wrote: Multi-adaptation: IFoo(one, two) Please note that this will break an incredible amount of code in the wild. A good number of my packages do something like this: foo = IFoo(context, None) if foo is None:

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Leonardo Rochael Almeida
I find it rather odd that we're wasting so much time worrying about backward incompatibility when we have a perfect mechanism to introduce backward incompatible changes in a way that allows both flavours to be used by packages in the same application (on a module by module basis just like Martijn

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martin Aspeli
Hanno Schlichting wrote: On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli optilude+li...@gmail.com wrote: Martijn Faassen wrote: This implies we don't want to release zope.component 4.0 for a long time yet. I think the answer should be never. :) I think never is a rather long time. I'd

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Wichert Akkerman
On 11/30/09 13:43 , Hanno Schlichting wrote: On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspelioptilude+li...@gmail.com wrote: Martijn Faassen wrote: This implies we don't want to release zope.component 4.0 for a long time yet. I think the answer should be never. :) I think never is a

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Hanno Schlichting
On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wich...@wiggy.net wrote: We could also say that we will clean up the API when we move to Python 3. That is a natural breaking point anyway, so it will not any extra pain for users of the ZCA. Except that is precisely what the Python developers

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Wichert Akkerman
On 11/30/09 14:45 , Hanno Schlichting wrote: On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkermanwich...@wiggy.net wrote: We could also say that we will clean up the API when we move to Python 3. That is a natural breaking point anyway, so it will not any extra pain for users of the ZCA.

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Stephan Richter
On Friday 27 November 2009, Martijn Faassen wrote: Are people okay with the proposed semantics? Would people be okay with such an upgrade path? Any better ideas? Looks good. Note: We had Thanks Giving over the weekend, so please allow more US people, like Jim, to comment before finalizing

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martin Aspeli
Hanno Schlichting wrote: On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wich...@wiggy.net wrote: We could also say that we will clean up the API when we move to Python 3. That is a natural breaking point anyway, so it will not any extra pain for users of the ZCA. Except that is precisely

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Gary Poster
On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Hi there, Introduction So now that we've had some discussion and to exit the bikeshed phase, Wow. That's abrupt, for something at the root of the entire stack. I don't think long emails are very effective, but I'm not

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Martin Aspeli wrote: Martijn Faassen wrote: [snip] That's why I think it's important to have a: * a zope.component 3.x that supports both patterns * a per-module way to indicate whether the new API should be used. Sorry, I just don't buy it. The *moment* someone requires = 4.0, you're

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really something fundamentally

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Leonardo Rochael Almeida wrote: I find it rather odd that we're wasting so much time worrying about backward incompatibility when we have a perfect mechanism to introduce backward incompatible changes in a way that allows both flavours to be used by packages in the same application (on a

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Thomas Lotze
Lennart Regebro wrote: On Sat, Nov 28, 2009 at 16:39, Charlie Clark The most common example I know of the syntax is with INameChooser() which brings us back to the differences (real or imaginary) between utilities and adapters. I agree that calling an interface like that is a strange

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really something

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Stephan Richter wrote: On Friday 27 November 2009, Martijn Faassen wrote: Are people okay with the proposed semantics? Would people be okay with such an upgrade path? Any better ideas? Looks good. Note: We had Thanks Giving over the weekend, so please allow more US people, like Jim, to

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Hey, [Python 3 discussions] I think discussions about Python 3 and changing the API then should be tabled in this thread. We're talking about a timeline where the first steps will take place in the next few months. Realistic small steps, please. (just like we'll need realistic small steps

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Stephan Richter wrote: On Friday 27 November 2009, Martijn Faassen wrote: Are people okay with the proposed semantics? Would people be okay with such an upgrade path? Any better ideas? Looks good. Note: We had Thanks

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Hey, Wichert Akkerman wrote: [snip] We could also say that we will clean up the API when we move to Python 3. That is a natural breaking point anyway, so it will not any extra pain for users of the ZCA. In my opinion, that would be the absolute worst possible moment. Motivation:

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Stephan Richter
On Monday 30 November 2009, Martijn Faassen wrote: * we can then allow tuple adaptation again. :) Tuple adaption was also really important to the Twisted guys. We should consult them to see whether they are still using zope.component and whether they are still adapting tuples. Regards,

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Hanno Schlichting
On Mon, Nov 30, 2009 at 5:09 PM, Martijn Faassen faas...@startifact.com wrote: Leonardo Rochael Almeida wrote:  * Use a different package name! We don't have that option, as we're talking about changing the behavior of calling IFoo. It's very well possible. You create a new distribution

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Hey, Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: [snip] So now that we've had some discussion and to exit the bikeshed phase, Wow. That's abrupt, for something at the root of the entire stack. I realize now that exiting the bikeshed phase was premature. Then

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Chris McDonough
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Stephan Richter wrote: On Monday 30 November 2009, Martijn Faassen wrote: * we can then allow tuple adaptation again. :) Tuple adaption was also really important to the Twisted guys. We should consult them to see whether they are still using zope.component and whether they are still

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Tres Seaver wrote: [snip] Do we really have a significant codebase which both needs to adapt tuples *and* uses the interface-calling sugar? I hope not. That's why I walk all over it breaking backwards compatibility in this plan. We'd need to live with IFoo((a, b)) for a few years as opposed

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martijn Faassen
Hanno Schlichting wrote: On Mon, Nov 30, 2009 at 5:09 PM, Martijn Faassen faas...@startifact.com wrote: Leonardo Rochael Almeida wrote: * Use a different package name! We don't have that option, as we're talking about changing the behavior of calling IFoo. It's very well possible. You

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Gary Poster
On Nov 30, 2009, at 11:51 AM, Chris McDonough wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Utility lookups versus adapter lookups -- There was some

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Lennart Regebro
On Mon, Nov 30, 2009 at 08:40, Wolfgang Schnerring w...@gocept.com wrote: Thus, we should not start requiring zope.component 4.0 everywhere immediately (because it's new, great and shiny ;), but rather use 3.9+future when we want to use the new semantics, and only after I don't know, 6 months

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Shane Hathaway
Martijn Faassen wrote: Given some feedback about backwards compatibility, I'm leaning to the following adjusted scenario: * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation. It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is* actually symmetric

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Lennart Regebro
On Mon, Nov 30, 2009 at 19:16, Shane Hathaway sh...@hathawaymix.org wrote: If adding lookup() is a good idea Possibly, but it sound like you are looking up (a), when in fact you are adapting it. :) Maye IFoo.adapt(a) ? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Matthias Lehmann
Am Montag 30 November 2009 16:57:11 schrieb Gary Poster: As above, I disagree. As a matter of mechanics, when you register something we call an adapter, it is a callable that takes one or more arguments. If we were going to follow the pattern that Marius laid out to establish what

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Shane Hathaway
Lennart Regebro wrote: On Mon, Nov 30, 2009 at 19:16, Shane Hathaway sh...@hathawaymix.org wrote: If adding lookup() is a good idea Possibly, but it sound like you are looking up (a), when in fact you are adapting it. :) Maye IFoo.adapt(a) ? +1, IFoo.adapt() is better, along with

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Chris McDonough
Shane Hathaway wrote: Martijn Faassen wrote: Given some feedback about backwards compatibility, I'm leaning to the following adjusted scenario: * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation. It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is*

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Gary Poster
On Nov 30, 2009, at 1:51 PM, Chris McDonough wrote: Shane Hathaway wrote: ...a good general argument, that Chris seemed to agree with and expand upon, and that has some merit to me. What do you think? + 1 with the following caveat: I think that method name should probably be adapt;

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Gary Poster
On Nov 30, 2009, at 11:47 AM, Martijn Faassen wrote: Hey, Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: ...snipping here and elsewhere without further warning... Utility lookup: IFoo() Named utility lookup: IFoo(name=foo) Utility lookup with a

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Charlie Clark
Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster gary.pos...@gmail.com: 1) I very much like the idea of some helpers hanging around. However, my current belief is that the factory methods ought to be callable objects that allow introspection of the underlying registry. That's where the

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Zvezdan Petkovic
On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: 3) I also think that utility is a bad name. Is singleton two letters too long? Yes and not because singleton is longer. It just a bad name. :-) ___ Zope-Dev maillist - Zope-Dev@zope.org

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Zvezdan Petkovic
On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote: On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: 3) I also think that utility is a bad name. Is singleton two letters too long? Yes and not because singleton is longer. It just a bad name. :-) To clarify because of 1. the

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Gary Poster
On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote: Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster gary.pos...@gmail.com: 1) I very much like the idea of some helpers hanging around. However, my current belief is that the factory methods ought to be callable objects that allow

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Gary Poster
On Nov 30, 2009, at 4:13 PM, Zvezdan Petkovic wrote: On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote: On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: 3) I also think that utility is a bad name. Is singleton two letters too long? Yes and not because singleton is longer. It just

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Zvezdan Petkovic
On Nov 30, 2009, at 4:40 PM, Gary Poster wrote: Put yet another way, how are 99+% of our utility usages not singletons? Therein lies the problem. Singletons are singletons in 100% of cases. Since utilities are not singletons in 100% of cases they are not singletons by definition. If that's

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Fred Drake
On Mon, Nov 30, 2009 at 5:14 PM, Lennart Regebro rege...@gmail.com wrote: True. For me utilities are tools. Like CMFs portal_whatever. But in Zope3 even small stupid singleton objects are utilities in some cases, and that is confusing for a beginner. I wonder how many typical Python

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Shane Hathaway
Gary Poster wrote: Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt a plug (required interface) so it can plugged in to

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martin Aspeli
Martijn Faassen wrote: The most elegant backwards compatible solution would be multi adaptation using a tuple. I think 'name' can probably also be added to the adapter hook without breaking stuff. People adapting tuples will need an explicit way to do so. It's still backwards incompatible,

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Martin Aspeli
Martijn Faassen wrote: Stephan Richter wrote: On Friday 27 November 2009, Martijn Faassen wrote: Are people okay with the proposed semantics? Would people be okay with such an upgrade path? Any better ideas? Looks good. Note: We had Thanks Giving over the weekend, so please allow more US

Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Laurent Mignon
Gary Poster wrote: On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote: Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt

Re: [Zope-dev] implementing zope.component 4.0

2009-11-29 Thread Martin Aspeli
Martijn Faassen wrote: Multi-adaptation: IFoo(one, two) Please note that this will break an incredible amount of code in the wild. A good number of my packages do something like this: foo = IFoo(context, None) if foo is None: ... There is a lot of documentation out there

Re: [Zope-dev] implementing zope.component 4.0

2009-11-29 Thread Adam GROSZER
Hello Hanno, Seems that that was an adapter heavy app. Was before the cut: len(getGlobalSiteManager()._utility_registrations) 980 len(getGlobalSiteManager()._adapter_registrations) 1432 len(getGlobalSiteManager()._handler_registrations) 63

Re: [Zope-dev] implementing zope.component 4.0

2009-11-29 Thread Wolfgang Schnerring
* Martijn Faassen faas...@startifact.com [2009-11-27 12:32]: Are people okay with the proposed semantics? +1, I think making these disappear into the language as much as possible is a Good Thing(tm). Would people be okay with such an upgrade path? Any better ideas? Yes, I'm okay with it. I do

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Martijn Faassen
Chris McDonough wrote: Martijn Faassen wrote: [snip] So now that we've had some discussion and to exit the bikeshed phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible. I suggest we think to

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Martijn Faassen
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Are people okay with the proposed semantics? +1. Would people be okay with such an upgrade path? Any better ideas? I would start issuign DeprecationWarnings (yes, I know I'm their worst fan,

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Martijn Faassen
Adam GROSZER wrote: I had a feeling that adapter lookup can be alone slowish with lots of registrations. We had a large project that was cut in half and the z3c.form UI, which is rather heavily adaptation based got a boost after that. Interesting. It'd be interesting to do some experiments

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Hanno Schlichting
On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen faas...@startifact.com wrote: Adam GROSZER wrote: I had a feeling that adapter lookup can be alone slowish with lots of registrations. We had a large project that was cut in half and the z3c.form UI, which is rather heavily adaptation based

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Charlie Clark
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: Well, I don't think the difference between adapters and utilities is important, but I can understand why some people find calling the interface odd: it is when you think about it objectively. I have to agree with this.

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Martijn Faassen
Charlie Clark wrote: Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers ch...@simplistix.co.uk: Well, I don't think the difference between adapters and utilities is important, but I can understand why some people find calling the interface odd: it is when you think about it objectively. I

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Charlie Clark
Am 28.11.2009, 16:06 Uhr, schrieb Martijn Faassen faas...@startifact.com: I have to agree with this. IFoo(myobject) is not intuitive. I know it used a lot because it's convenient shorthand but I've never read anywhere that interface classes are, in fact, callables. We certainly don't

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Lennart Regebro
On Sat, Nov 28, 2009 at 16:39, Charlie Clark charlie.cl...@clark-consulting.eu wrote: So adapters are reduced to type conversion? That's what adapters are. They aren't reduced to it, it's what they do. They adapt one object with one interface to have another interface. That can indeed be seen as

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Chris McDonough
Lennart Regebro wrote: I have very much come to appreciate the power of this delegation in, say, BrowserViews; even if it did take me several months to understand the multiadapter pattern! I hear this a lot, so this is apparently something that is common to take a while to grasp. Any ideas

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Chris McDonough
Martijn Faassen wrote: Chris McDonough wrote: Martijn Faassen wrote: [snip] So now that we've had some discussion and to exit the bikeshed phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible.

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Charlie Clark
Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro rege...@gmail.com: That's what adapters are. They aren't reduced to it, it's what they do. They adapt one object with one interface to have another interface. That can indeed be seen as a type conversion. I agree that that is probably the most

Re: [Zope-dev] implementing zope.component 4.0

2009-11-28 Thread Lennart Regebro
On Sat, Nov 28, 2009 at 17:35, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro rege...@gmail.com: That's what adapters are. They aren't reduced to it, it's what they do. They adapt one object with one interface to have another

[Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Martijn Faassen
Hi there, Introduction So now that we've had some discussion and to exit the bikeshed phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible. This means that I'll ignore backwards

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Thomas Lotze
Martijn Faassen wrote: Are people okay with the proposed semantics? I am. Would people be okay with such an upgrade path? Any better ideas? I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y) but maybe that changes after thinking about it some more. Most importantly,

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Chris Withers
Martijn Faassen wrote: Simple adaptation: IFoo(adapted) Is there an implied default of None here or would a ComponentLookupError be raised? Named adaptation: IFoo(adapted, name=foo) Adaptation with a default IFoo(adapted, default=bar) Multi-adaptation: IFoo(one,

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Marius Gedminas
On Fri, Nov 27, 2009 at 12:32:52PM +0100, Martijn Faassen wrote: Hi there, Introduction So now that we've had some discussion and to exit the bikeshed phase, let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Baiju M
from zope.__future__ import new_adapter_lookup? Let's leave how special names are created in Python to Python. We already have __parent__, __annotation__ etc. What if Python brings a special name which we are using with a different semantics. May be we can use special prefix for Zope's own

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Martijn Faassen
Thomas Lotze wrote: Martijn Faassen wrote: Are people okay with the proposed semantics? I am. Would people be okay with such an upgrade path? Any better ideas? I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y) but maybe that changes after thinking about it

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Martijn Faassen
Chris Withers wrote: [snip] I'd propose just having: 3.x - old semantics 4.x - new semantics That's the Python 3 upgrade scenario, without conversion scripts even. :) I think this would block people from upgrading to use the new semantics way too long, as they'd need to ensure all their

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Martijn Faassen
Marius Gedminas wrote: [snip] +0.5 --- I can live with it. Backwards incompatibility with IFoo(one, default) will be a slight inconvenience. There were proposals I liked more (IFoo.adapt(), IFoo.utility()) and proposals I liked less (IFoo((one, two, we_like_parentheses,

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Martijn Faassen
Chris Withers wrote: Martijn Faassen wrote: Simple adaptation: IFoo(adapted) Is there an implied default of None here or would a ComponentLookupError be raised? I'd say a ComponentLookupError. Doesn't it do that now? Anyway, I'd say if you want a default specify it, otherwise it'll

Re: [Zope-dev] implementing zope.component 4.0

2009-11-27 Thread Martijn Faassen
Baiju M wrote: from zope.__future__ import new_adapter_lookup? Let's leave how special names are created in Python to Python. We already have __parent__, __annotation__ etc. What if Python brings a special name which we are using with a different semantics. Python's not going to

  1   2   >