Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the main API to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. 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 ) -- Brian Sutherland ___ 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] implementing zope.component 4.0
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 really very similar to this. The main difference is that we don't use the concrete implementation's factory but that we use the interface that specifies the abstract behavior. That is a difference, but doesn't seem to be a huge step in my mind. Thanks for the comparison but it is semantically so different and interfaces can be used for things other than adapters that I disagree. 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 don't think it's that different at all semantically if you think of it. I think what you're getting at with the name chooser example is that adapters are not really used for conversion but for accessing a *feature* for an object. This was in fact an old proposed name for adapters in Zope 3. So, with INameChooser you'd like the name chooser feature for a container. And int() *can* be seen as wanting the integer feature for a particular string. But that's not as convincing as the example of len in Python. 'len()' asks for the size feature for an object (a list, a string, a dict, etc). The difference here is that with conversion, often the original value is considered to be unimportant anymore - once I have my integer I can forget my string. That's not the case with len - the original object is still there and relevant. With adaptation both patterns exist, but the feature pattern is more common. To step away from adaptation for a bit, I find utility lookups interesting to compare with imports in Python. The import statement in Python is used to import a single global instance of a particular thing (an instance, or a module instance). Implicitly the importing code expects the imported thing to fulfill a particular interface. A utility lookup does something very similar, except that the interface is made explicit and it's more easy to plug in alternatives. I've toyed around with the idea of turning utility lookup into imports: from foo.bar.baz import IFoo as foo would be the equivalent of: foo = component.getUtility(IFoo) But unfortunately this idea has some drawbacks: * how to handle named utilities and defaults? * I suspect it cannot be easily implemented at all. :) * most unfortunately, imports are usually done on module-level during import time while utility lookups *cannot* be done on module-level because during import time the utility registry is not initialized yet. So in fact we need to do this in two steps: import something for the utility during import time, and then during run time do the actual utility lookup. That's exactly what this would do: from foo.bar.baz import IFoo def main(): foo = IFoo() [snip] It's quite likely that I'm wrong in this but I see great potential using adapters for delegation rather than straight conversion. 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! Delegation is indeed a special property that conversion and feature patterns in plain Python don't have (unless I missed an example). The thing that is returned in plain Python is usually of a type that's so well known by the programmer it disappears into the background. With adapters this is less common. My proposal hopes to make some of these types appear into the background a bit more too, though. Because I do, repeatedly, make simple mistakes with the adapter, utility (wrong name, wrong signature) stuff I very much appreciate attempts to simplify and clarify the API. But I will greet them the same poor grasp of the underlying concepts than I did the originals! I agree that we should *also* work at explaining the underlying concepts more and better. 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] implementing zope.component 4.0
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 while to grasp. Any ideas of what to make multi-adapters more understandable would probably be a good thing. The typical misunderstanding starts like this, I think: [snip scenario] Personally, even I don't really know how it works. I think this scenario is actually a lot more common among those of us (you and me) who *do* have an idea of what multi adaptation actually does. :) I think what you are describing is a lack of understanding of the detailed mechanism. Perhaps it's different for you, but I haven't heard stories of beginners being confused by this. I think you only tend to run into this if you do something quite advanced with the ZCA, i.e. build frameworky things yourself. That said, better documentation would again be useful. 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] implementing zope.component 4.0
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 would break a lot of code is well known [backwards compatibility discussion] -1 Because we now have so many packages and things are being released as eggs and mixed up in various platforms and projects, this type of gross backwards incompatibility is virtually impossible to manage. To take an example, I'm sure Stefan co will release z3c.form 3 depending on zope.component 4 before long, and we'll want to use that in Plone. Except we can't, because even if z3c.form never uses the IFoo(one, two) syntax, everything in Plone that uses IFoo(context, None) would suddenly break. 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. We'd commit to maintaining zope.component 3.x in parallel with zope.component 4.0. We'd recommend to people *not* to require zope.component 4.0 for a period, or perhaps we'd even not release it for quite a period. The documentation issue is a more severe one. [snip] I think Jim said once, we can't ever have backwards incompatibility. Other serious platforms like Java or .NET have a similar stance. They deprecate liberally, but never actually break anything. (Remember java.util.Data and java.util.Calendar?) No, I don't remember. :) We may never be able to do that completely, and we may *want* to root out some dodgy bits of code that few people use. But breaking something so fundamental and so commonly used would be criminal, in my book. Taken into consideration. I think it's important not to do a big bang upgrade but instead allow people to upgrade bit by bit. It should be possible to compose an application that mixes code that expects the old semantics with code that expects the new semantics. A bit by bit upgrade I think would ideally be on a per-module basis. I think it's important to make sure we can support such an upgrade *before* we release any of this. I'm not sure that's going to be possible. As soon as someone does zope.component = 4.0 in their setup.py, you're screwed. This implies we don't want to release zope.component 4.0 for a long time yet. 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] implementing zope.component 4.0
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 their code. (The deprecation warnings proposed elsewhere should help there, I think this is a good use case for them.) 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 maybe, start switching over completely. I agree. If we go this route, we should delay a release of zope.component 4.0 for a significant period so we don't get code depending on it. That may be quite a bit longer than 6 months. I'd be nice if we could express dependencies like: zope.component 3.11 or zope.component 4.0 but I don't think that's supported yet. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Sun Nov 29 12:00:00 2009 UTC to Mon Nov 30 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Nov 29 20:38:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013107.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Nov 29 20:40:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013108.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:42:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013109.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:44:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013110.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:46:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013111.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Nov 29 20:48:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013112.html ___ 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] implementing zope.component 4.0
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: ... Yes, that this would break a lot of code is well known Yeah. I'm kind of astonished at how many people are happy to accept that, though. [backwards compatibility discussion] -1 Because we now have so many packages and things are being released as eggs and mixed up in various platforms and projects, this type of gross backwards incompatibility is virtually impossible to manage. To take an example, I'm sure Stefan co will release z3c.form 3 depending on zope.component 4 before long, and we'll want to use that in Plone. Except we can't, because even if z3c.form never uses the IFoo(one, two) syntax, everything in Plone that uses IFoo(context, None) would suddenly break. 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 screwed. And per-module flags are ugly and confusing. I'm quite sure most people never import from __future__ in Python, just because it's so hard to see what's going on and so annoying to have to remember to do it. We'd commit to maintaining zope.component 3.x in parallel with zope.component 4.0. We'd recommend to people *not* to require zope.component 4.0 for a period, or perhaps we'd even not release it for quite a period. This sounds like we're making excuses for making a bad choice. What's the point of releasing a package if we encourage people not to use it? Or not to use it yet? When does yet end? We won't be able to control what people do in their code. And it only takes one package to depend on 4.0 for it to all go wrong for anyone using the current, documented, *encouraged* pattern. The documentation issue is a more severe one. And not one that we can brush aside. It's criminal. I'm going to have to go and update a ton of documentation and say, you need to figure out which version you're on; if you're on version 4, this bit of code does this; if you're on version 4.0 or later, it does something entirely different. To do that *intentionally* is just wrong. Most people don't even know how to figure out which version they're using. For most people, it involves opening binaries in the bin/ director of their buildout and check out the sys.path mangling. [snip] I think Jim said once, we can't ever have backwards incompatibility. Other serious platforms like Java or .NET have a similar stance. They deprecate liberally, but never actually break anything. (Remember java.util.Data and java.util.Calendar?) No, I don't remember. :) Count yourself lucky. ;) We may never be able to do that completely, and we may *want* to root out some dodgy bits of code that few people use. But breaking something so fundamental and so commonly used would be criminal, in my book. Taken into consideration. I think it's important not to do a big bang upgrade but instead allow people to upgrade bit by bit. It should be possible to compose an application that mixes code that expects the old semantics with code that expects the new semantics. A bit by bit upgrade I think would ideally be on a per-module basis. I think it's important to make sure we can support such an upgrade *before* we release any of this. I'm not sure that's going to be possible. As soon as someone does zope.component = 4.0 in their setup.py, you're screwed. This implies we don't want to release zope.component 4.0 for a long time yet. I think the answer should be never. :) To put this into perspective: we're going to cause a lot of pain for a lot of people for something that is *purely* cosmetic. We're indulging in a whim for perfect API design at the expense of people who signed up to our old API. Sometimes, we need to accept that our past decisions are with us to stay. I think that's a sign of maturity and attention to our customers, rather than weakness. There are solutions in these threads which are backwards compatible, or at least backwards compatible in the vast majority of cases. They may not be exactly as pretty, but in my book they are infinitely preferable. I would much, much rather have none of these improvements and not break all that code. What we have now works. We would just like it to be a little bit prettier and a bit more obvious. Those are laudable goals, but not at any expense. And yeah, I feel pretty strongly about this. ;-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev
Re: [Zope-dev] implementing zope.component 4.0
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 would like): * Use a different package name! Yes, I know, zope.component and zope.interface are such clear and nice names, and it'd be a shame to let them go for the sake of a new and better API. But why should we even go down the route of backward incompatibility? We can keep the backward compatibility forever while having zero code duplication by implementing the old API on top of the newer one. It's what we've been doing all these years on zope.app namespace and even on the Zope 2 codebase. It's a tried and true method. It's not like we're changing the core Python language in a way as to correct previous uncorrectable mistakes. It's just a couple of pakages! And to have a little bit more of bike sheds to paint, I'll even suggest the new names: zc.component and zc.interface. We'll even save a couple of bytes on every import. Cheers, Leo On Mon, Nov 30, 2009 at 10:43, Hanno Schlichting ha...@hannosch.eu 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 suggest we think about these changes more in the timeline of years. Looking at Python itself or Zope's own former deprecation policies, it seems that policies where we deprecate / warn about API changes in one release and change behavior it one or two releases after that seem to work. They do rely on their being something like a coherent release of some language / framework / toolkit though. And they rely on these releases being made at an interval of at minimum a year or preferably 18 months (as in Python's case). I think that once we get a ZTK 1.0 release out that promises to be maintained for at least three years, we can start working on a ZTK 2.0 which introduces deprecation warnings about the changed behavior and a 3.0 that will change the default. If released at an interval of 18 months like Python, that puts these changes about 3 years into the future with a lot of time in between to adjust. Given such an approach I think we can indeed change core API's in backwards incompatible ways. Python itself does this all the time, look at Exceptions as new-style classes, new language keywords like with or the massive amount of changes in Python 3. But if we treat zope.component / zope.interface just as two packages of their own, I'd agree that we don't have any way to provide reasonable backwards compatibility and ensure that some packages won't use these straight away. The whole point of the toolkit is to ensure we have a large number of packages that are compatible and tested with each other. Hanno ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
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 suggest we think about these changes more in the timeline of years. Looking at Python itself or Zope's own former deprecation policies, it seems that policies where we deprecate / warn about API changes in one release and change behavior it one or two releases after that seem to work. They do rely on their being something like a coherent release of some language / framework / toolkit though. And they rely on these releases being made at an interval of at minimum a year or preferably 18 months (as in Python's case). I think that once we get a ZTK 1.0 release out that promises to be maintained for at least three years, we can start working on a ZTK 2.0 which introduces deprecation warnings about the changed behavior and a 3.0 that will change the default. If released at an interval of 18 months like Python, that puts these changes about 3 years into the future with a lot of time in between to adjust. Given such an approach I think we can indeed change core API's in backwards incompatible ways. Python itself does this all the time, look at Exceptions as new-style classes, new language keywords like with or the massive amount of changes in Python 3. But if we treat zope.component / zope.interface just as two packages of their own, I'd agree that we don't have any way to provide reasonable backwards compatibility and ensure that some packages won't use these straight away. The whole point of the toolkit is to ensure we have a large number of packages that are compatible and tested with each other. I agree with your argument in general terms, but I think breaking this kind of thing is something we should *never* do lightly. It will always cause pain for a lot of people, not at least extra work to change a lot of code. If there's a good reason, we can sometimes do this on the type of basis you're suggesting. I don't consider a desire for the perfect API to be such a good reason. The alternatives that are (virtually) backwards compatible are not so bad that the marginal improvement of *args instead of taking a tuple (for example) are worth it. IMHO. ;-) I'm being rather forceful here, but I think it's an important point. If something is really broken or has dangerous side effects, we have a case for breaking backwards compatibility. If we just think it'd be a bit prettier to have it another way, then we don't. Living by past decisions is a part of being good software engineers, and the kind of thing that your customers actually love you for. Martin P.S. I don't agree with Python 3(000) either, but I've kept my mouth shut about that one. I would point out, though, that Python 3 doesn't have a stellar uptake at the moment. -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] implementing zope.component 4.0
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 rather long time. I'd suggest we think about these changes more in the timeline of years. Looking at Python itself or Zope's own former deprecation policies, it seems that policies where we deprecate / warn about API changes in one release and change behavior it one or two releases after that seem to work. They do rely on their being something like a coherent release of some language / framework / toolkit though. And they rely on these releases being made at an interval of at minimum a year or preferably 18 months (as in Python's case). I think that once we get a ZTK 1.0 release out that promises to be maintained for at least three years, we can start working on a ZTK 2.0 which introduces deprecation warnings about the changed behavior and a 3.0 that will change the default. If released at an interval of 18 months like Python, that puts these changes about 3 years into the future with a lot of time in between to adjust. 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. 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] implementing zope.component 4.0
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 have asked everyone not to do. So far the story is that the upgrade to Python 3 can be done largely automatic and a codebase for 2.x and 3.x can be maintained automatically and kept in sync. Once you introduce semantic instead of syntactic differences outside Python 3 itself into the whole mix, it gets virtually impossible to maintain a codebase that works on both 2.x and 3.x. So while the Python 3 uptake is still slow, I think we shouldn't add more roadblocks onto that path. 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] implementing zope.component 4.0
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. Except that is precisely what the Python developers have asked everyone not to do. So far the story is that the upgrade to Python 3 can be done largely automatic and a codebase for 2.x and 3.x can be maintained automatically and kept in sync. In theory. I am convinced that in practice you well end up with code that is un-pretty in both python 2.x and 3.x, and harder to debug. Python 3 also introduces changes that warrant API changes, so not making them could lead to awkward APIs. Personally I will take the liberty to change the API of any of my packages if and when I port them to Python 3. 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] implementing zope.component 4.0
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 the decision. 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] improving the utility and adapter lookup APIs
On Nov 30, 2009, at 4:05 AM, Brian Sutherland wrote: On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the main API to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. I'd argue what you have is pretty obscure though--that is, reading your code example, I'd have to stare at it a while to figure out why it works, and I know the component machinery pretty well. The IDefaultPublishTraverse thing would be inelegant but much more readable. I'd want to think about this class of use cases harder if it were regarded as an important one. I am myself somewhat interested in being able to turn off the short-circuit behavior explicitly if desired. That said, for multiadapters involving more than one required object, IMO the short-circuit behavior should never be invoked. It is not clear that the first object is the one that should be checked for already providing the desired interface. Therefore, in this particular usage, ``IPublishTraverse(self, request)`` would do what you want. Gary ___ 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] implementing zope.component 4.0
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 what the Python developers have asked everyone not to do. So far the story is that the upgrade to Python 3 can be done largely automatic and a codebase for 2.x and 3.x can be maintained automatically and kept in sync. That's a nice theory, but experience suggests it'll be a right mess. Is anyone doing this successfully on a project of a comparable size to Zope? Or Plone? It sounds like fantasy to me. Why? Because if the compatibility really was that mechanical there would probably be a way to run Python 2 code in Python 3 - and there isn't. Once you introduce semantic instead of syntactic differences outside Python 3 itself into the whole mix, it gets virtually impossible to maintain a codebase that works on both 2.x and 3.x. This feels like we're trying to solve a different problem. So while the Python 3 uptake is still slow, I think we shouldn't add more roadblocks onto that path. A laudable goal, but I don't think it should be a consideration here. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] implementing zope.component 4.0
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 sure how else to reply to your long email. 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 compatibility while sketching out the ideal semantics below - I have the impression we can get consensus on the following behavior: Simple adaptation: IFoo(adapted) Named adaptation: IFoo(adapted, name=foo) Adaptation with a default IFoo(adapted, default=bar) Multi-adaptation: IFoo(one, two) Named multi adaptation: IFoo(one, two, name=foo) Multi-adaptation with a default: IFoo(one, two, default=bar) I am in favor of the above, given a backwards compatibility story that makes existing packages work. Utility lookup: IFoo() Named utility lookup: IFoo(name=foo) Utility lookup with a default: IFoo(default=bar) I disagree with this. More below. Where name and default can be combined. The name and default keyword parameters have to be used explicitly - *args is interpreted as what to adapt only. Any other keyword parameters should be rejected. Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really something fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. 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 happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. Two by-the-ways: 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? IMO, they are not. Our usage of adapter is as a factory. Yes, it can be used in other ways--so can a Python class--but that is the essence of how our community uses this technology. Calling all these ideas adapters accomplishes nothing. Explaining all of the ideas as a factory to produce an object that provides the interface cleanly describes our usage, and both adapters and multiadapters. (To be complete, I am in favor of ditching subscription adapters in favor of other mechanisms related to named singleton lookups.) One reason I like the syntax proposals for the adapter change is that they treat the interfaces as pluggable factories. This is apt. 2) The term utility is another barrier to understandability. They are singletons. Explaining them as such is a well, why didn't you say so experience. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. Moreover, I think that some of the use cases that Marius referred to for underpowered utilities coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. Features off the table for now --- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. It seems to me that this, along with the documentation call that Chris gave, is a much more valuable immediate effort. One of the biggest complaints I heard was with debugging. I've spent some thought on the debugging story, and have some APIs sketched out in my experiments--it was one of the first things I
Re: [Zope-dev] implementing zope.component 4.0
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 screwed. See discussion below. And per-module flags are ugly and confusing. I'm quite sure most people never import from __future__ in Python, just because it's so hard to see what's going on and so annoying to have to remember to do it. From future imports are going to be part of our life for a significant period, as we go through Python 2.6 and then presumably, sometime, to Python 3.x. We'd commit to maintaining zope.component 3.x in parallel with zope.component 4.0. We'd recommend to people *not* to require zope.component 4.0 for a period, or perhaps we'd even not release it for quite a period. This sounds like we're making excuses for making a bad choice. What's the point of releasing a package if we encourage people not to use it? Or not to use it yet? When does yet end? We won't be able to control what people do in their code. And it only takes one package to depend on 4.0 for it to all go wrong for anyone using the current, documented, *encouraged* pattern. So I'm adjusting my story to say we shouldn't release zope.component 4.0 at all. We should first go through zope.component 3.x which gives: * a deprecation error if 'default' is not used explicitly. * a from future mode so that the new semantics can be used on a per-module basis. [snip documentation issue being severe, if not criminal] I think it's important not to do a big bang upgrade but instead allow people to upgrade bit by bit. It should be possible to compose an application that mixes code that expects the old semantics with code that expects the new semantics. A bit by bit upgrade I think would ideally be on a per-module basis. I think it's important to make sure we can support such an upgrade *before* we release any of this. I'm not sure that's going to be possible. As soon as someone does zope.component = 4.0 in their setup.py, you're screwed. This implies we don't want to release zope.component 4.0 for a long time yet. I think the answer should be never. :) To put this into perspective: we're going to cause a lot of pain for a lot of people for something that is *purely* cosmetic. We're indulging in a whim for perfect API design at the expense of people who signed up to our old API. Sometimes, we need to accept that our past decisions are with us to stay. I think that's a sign of maturity and attention to our customers, rather than weakness. Tell that to the Python core developers. :) Anyway, I'm a bit more flexible on the issue of backwards compatibility. But the deeper in the stack we are the more careful we should be, indeed, as there are many consumers, directly and indirectly. There are solutions in these threads which are backwards compatible, or at least backwards compatible in the vast majority of cases. They may not be exactly as pretty, but in my book they are infinitely preferable. I would much, much rather have none of these improvements and not break all that code. What we have now works. We would just like it to be a little bit prettier and a bit more obvious. Those are laudable goals, but not at any expense. 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, but the impact is less big. In any case, I would like to deprecate non-explicit keywords parameters for 'default' and 'name'. 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] implementing zope.component 4.0
-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 different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. As above, I disagree. 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 implementing IFoo, looked up using some number N of context arguments, where N could be 0 (no context required to find the object). The fact that, under the hood, an adapter lookup happens to call a factory, passing the context args, is not relevant *to the caller*. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksT7n8ACgkQ+gerLs4ltQ6vZwCfTT8aWbm4WO7Ba6nQiNPohM3Y QWsAnRUtVRFFQlDRbpnyRao0NZA/mjo3 =VfyQ -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] implementing zope.component 4.0
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 module by module basis just like Martijn would like): * Use a different package name! We don't have that option, as we're talking about changing the behavior of calling IFoo. The options are: * changing the signature of calling IFoo in a backwards incompatible way, with various transition strategies. * changing the signature of calling IFoo in an almost backwards compatible way (breaking tuple adaptation) * adding new methods to IFoo. 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] implementing zope.component 4.0
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 thing to do. I don't know what that would do, even. I have however never ever seen that done. To me, it feels rather naturally like calling a class: both give you an object that has a well-defined relation to what you called, i.e. is an instance of the class or provides the interface. Both relations are very similar IMO in that they describe how the object behaves and what you can do with it, the difference being only that calling an interface adds some abstraction and flexibility. -- Thomas ___ 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] implementing zope.component 4.0
-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 fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. As above, I disagree. 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 implementing IFoo, looked up using some number N of context arguments, where N could be 0 (no context required to find the object). The fact that, under the hood, an adapter lookup happens to call a factory, passing the context args, is not relevant *to the caller*. (Sorry for the self-followup: I hit the send key combo by accident). As an additional point: note that 'IFoo(context)' does *not* guarantee that any factory will be called at all: if 'context' already provides IFoo, then it is just returned. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksT8FoACgkQ+gerLs4ltQ5Q3QCdFqvt7BP+SPEiBY6ptsDrj/T5 MPUAn24YiKOtR6gF3B3YhEjgrGkBtqEX =qUsq -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] Proposal: zope.app.publisher refactoring
Hi Michael I just implemented z3c.authviewlet and moved the authentication viewlet part from z3c.layer.pagelet into this new package. The z3c.layer.pagelet package does not use the z3c.authviewlet package as a dependency. This means you need to include the z3c.authviewlet package in your buildout.cfg and configure it in your configure.zcml. I just released both packages. Regards Roger Ineichen -Ursprüngliche Nachricht- Von: Michael Howitz [mailto:m...@gocept.com] Gesendet: Dienstag, 22. September 2009 10:43 An: d...@projekt01.ch Cc: Zope Developers Betreff: Re: AW: AW: [Zope-dev] Proposal: zope.app.publisher refactoring Am 25.08.2009 um 14:39 schrieb Roger Ineichen: [...] I was looking another time at the z3c.layer.pagelet package. I agree that the added authentication support is useful and was missing in the first releases. The loginForm.html pagelet should stay there. But we should move the viewlets to another package since this is optional and another concept which is not really needed by pagelets. e.g. z3c.authviewlet or so. Right. Nice naming idea, I'll put it on my to do list. Another reason for moving this viewlets is that this login/ logout viewlets are useful too without using pagelets. Right, too. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] implementing zope.component 4.0
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 comment before finalizing the decision. Good point. We'll give it some more time. 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 with registration. * deprecate a non-explicit default such as IFoo(a, default), require IFoo(a, default=default) * do the other stuff (name, utility lookups, etc) * this will be a zope.component 3.x release. Or we could even call it 4.0. * we can stick with this for quite a while. * in some years time, see about allowing IFoo(a, b) for multi adaptation. By that time people will have updated their code to use explicit defaults everywhere. * then deprecate IFoo((a, b)) in favor of IFoo(a, b) * we can then allow tuple adaptation again. :) 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] implementing zope.component 4.0
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 towards Python 3. these are in fact taking place) 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] implementing zope.component 4.0
-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 Giving over the weekend, so please allow more US people, like Jim, to comment before finalizing the decision. Good point. We'll give it some more time. 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 with registration. * deprecate a non-explicit default such as IFoo(a, default), require IFoo(a, default=default) * do the other stuff (name, utility lookups, etc) * this will be a zope.component 3.x release. Or we could even call it 4.0. * we can stick with this for quite a while. * in some years time, see about allowing IFoo(a, b) for multi adaptation. By that time people will have updated their code to use explicit defaults everywhere. * then deprecate IFoo((a, b)) in favor of IFoo(a, b) * we can then allow tuple adaptation again. :) Do we really have a significant codebase which both needs to adapt tuples *and* uses the interface-calling sugar? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksT8dkACgkQ+gerLs4ltQ6njACfVnCur+u1slEsMVg/Xb4APKJt jSMAnApmfLnCJkJ2venr+nOux8dazjWa =3Hpn -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] implementing zope.component 4.0
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: http://faassen.n--tree.net/blog/view/weblog/2008/03/05/0 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] implementing zope.component 4.0
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, 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] implementing zope.component 4.0
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 called for example Interface. Now you can write: import interface import zope.interface class IFoo(interface.Interface): pass class IBar(zope.interface.Interface): pass Depending on what kind of interface you have the semantics of calling these are different. Not that I'm proposing to do this, as it leads to a pretty horrible mess, but it's possible. We are just now getting rid of the old Zope2 Interface package and its usage in Plone land, which has the same kind of incompatibility problem. I expect that old version of interfaces is still going to be with us for a number of years. So experience shows that something so central, even if not used for many important things, has a much much longer lifetime than you'd expect. 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] implementing zope.component 4.0
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 again, we don't want to go into circles about APIs forever. Recent discussions were focused on backwards compatibility, so that's progress. [snip] I am in favor of the above, given a backwards compatibility story that makes existing packages work. Yay! Utility lookup: IFoo() Named utility lookup: IFoo(name=foo) Utility lookup with a default: IFoo(default=bar) I disagree with this. More below. [snip] 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 happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. I still don't see why that isn't an implementation detail. How we get an IFoo doesn't concern us when we're calling it, as long as we get an IFoo? Even with adaptation a singleton could be returned; it's just the implementation of such would be different. If we take Marius' pattern, registring a singleton directly would simply be a shortcut API for registring a factory for utilities. (Utility factories would make it easier to implement local utilities that aren't ZODB-backed...) That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. What is this valuable semantic? [snip] (To be complete, I am in favor of ditching subscription adapters in favor of other mechanisms related to named singleton lookups.) I really need to think through subscription adapters; I haven't done any analysis about those. 2) The term utility is another barrier to understandability. They are singletons. Explaining them as such is a well, why didn't you say so experience. Another way to explain utilities is that getting a utility is a lot like importing something in Python, except that what is imported is pluggable and the required interface is specified explicitly. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. import by interface to me sounds like it'd clarify matters for more Python programmers. Singleton has all kinds of design pattern connotations that don't really apply here. Moreover, I think that some of the use cases that Marius referred to for underpowered utilities coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. I don't understand. Could you rephrase? Features off the table for now --- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. It seems to me that this, along with the documentation call that Chris gave, is a much more valuable immediate effort. One of the biggest complaints I heard was with debugging. I've spent some thought on the debugging story, and have some APIs sketched out in my experiments--it was one of the first things I worked on. To do it cleanly (the way I envision) would require some work, but a first cut wouldn't be too bad. Hm, I disagree about what's more valuable. I'd be quite happy when I can grab utilities and multi adapters without having to refer to zope.component all the time. Being able to look up an adapter without calling it in a convenient manner, not so. But multiple efforts can certainly take place in parallel, if we have to volunteers. [snip] I share Baiju's dislike of inventing __*__ names. What is the necessity? At least __future__ has precedence, I suppose, but Python devs have expressed their opinion clearly now that __*__ is theirs, and I think we should respect it in upcoming decisions. Ah, I vaguely recalled something about __*__ being theirs now, but wasn't sure. Finally, per Martin's points, I'm not sure zope.component can actually ever deprecate the old spelling, so I'm not sure __future__ has the right semantic. This is really __alt__ or something, IMO. I think it can deprecate the old spelling and eventually
Re: [Zope-dev] implementing zope.component 4.0
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 adapting tuples. Hm, could I delegate you to contact the right people on this? And whether they are using the adapter hook for it? 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] implementing zope.component 4.0
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 to IFoo(a, b), but if that means we can move forward without breaking a lot of code, I think we should take that hit. Maybe we'll like it enough that we never really need IFoo(a, b) after all. 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] implementing zope.component 4.0
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 create a new distribution called for example Interface. Now you can write: import interface import zope.interface class IFoo(interface.Interface): pass class IBar(zope.interface.Interface): pass Depending on what kind of interface you have the semantics of calling these are different. Not that I'm proposing to do this, as it leads to a pretty horrible mess, but it's possible. True. But nitpicking, as all along we're talking about an upgrade to zope.component to allow new semantics. We are just now getting rid of the old Zope2 Interface package and its usage in Plone land, which has the same kind of incompatibility problem. I expect that old version of interfaces is still going to be with us for a number of years. So experience shows that something so central, even if not used for many important things, has a much much longer lifetime than you'd expect. Agreed. By taking everything along at the same time in this case I think we avoid this issue somewhat, though. 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] implementing zope.component 4.0
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 discussion on whether utility lookups are really something fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. As above, I disagree. 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 implementing IFoo, looked up using some number N of context arguments, where N could be 0 (no context required to find the object). The fact that, under the hood, an adapter lookup happens to call a factory, passing the context args, is not relevant *to the caller*. I understand that the idea explained above is conceptually integral to a lot of people, and basically unquestionable. But as devil's advocate sort of thing can we put this traditional worldview aside for a minute, and just sort of take this from ground zero? In normal Python, callers often do need to understand whether the function they're calling is a factory which constructs a new object, or a function which returns a global, because the caller needs to know what the impact of mutating the result is. We call non-factories utilities and we call factories adapters. So the caller *already* needs to make a distinction between the two. Yes. Gary ___ 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] implementing zope.component 4.0
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 maybe, start switching over completely. Six months? :) The last non-alpha release of Plone is 3.3.2, which runs on Zope 2.10.9, which uses Zope 3.3.2, released over two years ago. If we are to break backwards compatibility we need to make a deprecation warning, and let that run until the large body of Plone code has gotten that deprecation warning and been able to move over to either a future syntax or some other syntax before we can actually break the backwards compatibility. So if you multiply those 6 month with 5, then maybe that path forward is feasible. If we want to change the API faster, we need a backwards compatible way, and as mentioned, there doesn't seem to be one. On Mon, Nov 30, 2009 at 14:45, Hanno Schlichting ha...@hannosch.eu 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 what the Python developers have asked everyone not to do. This is true. But the fact is that we don't have any choice. The current 2.x syntax simply doesn't work under Python 3. We *must* change the API, and we will do that by moving implements() to @implementor. So far the story is that the upgrade to Python 3 can be done largely automatic and a codebase for 2.x and 3.x can be maintained automatically and kept in sync. And this is still true if you write a fixer for it. So that means we must write a fixer that changes IFoo(bla, bleh) to IFoo(blah, default=bleh). Writing fixers are High Magic, but throw tons of testcases on it and some trial and error works. :) So cleaning up the API for Python 3 is fine, IMNSHO. It will be slightly kludgy to implement it though, but doable. On Mon, Nov 30, 2009 at 16:40, Martin Aspeli optilude+li...@gmail.com wrote: That's a nice theory, but experience suggests it'll be a right mess. Is anyone doing this successfully on a project of a comparable size to Zope? Or Plone? It sounds like fantasy to me. Why? Because if the compatibility really was that mechanical there would probably be a way to run Python 2 code in Python 3 - and there isn't. No, of course nobody has done it with a project of comparable size to Zope and Plone. Is there one even? :-) But that wouldn't be a problem I think. Martin von Löwis has made test-ports of both ZODB and Django to Python 3. The problem is that there are tons of developers involved in the Plone community making a lot of popular and well used third-party components, and getting all of them to support both Python 2 and Python 3 at around the same time (I mean within the same year) seems unlikely, and that risks ending up in a catch 22 situation where nobody moves to Python 3 because nobody else has. But that's a different discussion. Although I have no problems with changing the API for Python 3, both that option and the option of making a slow deprecating means that we can't actually break backwards compatibility for a couple of years anyway. What other options are there? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] implementing zope.component 4.0
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 with registration. * deprecate a non-explicit default such as IFoo(a, default), require IFoo(a, default=default) While this short spelling of component lookup is attractive and sensible for Zopistas, I wonder if it ever really was the best idea. When a developer encounters the IFoo() pattern for the first time, what is he/she going to type into a search engine to find out what it means? I can't think of any search phrase that is likely to give a good answer. JQuery has a similar issue, but because JQuery is a smaller framework, the JQuery folks simply put that info right near the top of their documentation. I'm not sure we can do that quite as effectively. For an alternate spelling, consider what happens when component lookup fails: you get a ComponentLookupError. Lookup is interesting. It doesn't yet have any meaning in zope.interface, so I think using a method named lookup() would make code more comprehensible. You would use it like this: IFoo.lookup(a) SomeAdapter instance at ... IFoo.lookup(a, b) SomeMultiAdapter instance at ... IFoo.lookup(c) Traceback... ComponentLookupError(...) IFoo.lookup(c, default='missing') 'missing' IMyUtility.lookup() MyUtility instance at ... When developers encounter this for the first time, they might type zope.interface lookup in a search engine. That phrase has a reasonable chance of hitting good documentation. What do you think? If adding lookup() is a good idea, then all we need to do is add lookup() to zope.interface 3.x and deprecate the 2nd parameter of IFoo(). After that, we can let multi-year evolution dictate whether IFoo() should be deprecated altogether. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
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/ +33 661 58 14 64 ___ 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] implementing zope.component 4.0
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 happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. Two by-the-ways: 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? IMO, they are not. Our usage of adapter is as a factory. Yes, it can be used in other ways--so can a Python class--but that is the essence of how our community uses this technology. Calling all these ideas adapters accomplishes nothing. Explaining all of the ideas as a factory to produce an object that provides the interface cleanly describes our usage, and both adapters and multiadapters. (To be complete, I am in favor of ditching subscription adapters in favor of other mechanisms related to named singleton lookups.) One reason I like the syntax proposals for the adapter change is that they treat the interfaces as pluggable factories. This is apt. 2) The term utility is another barrier to understandability. They are singletons. Explaining them as such is a well, why didn't you say so experience. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. Moreover, I think that some of the use cases that Marius referred to for underpowered utilities coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. I understand that most of us find IFoo(x, y) looks just beautiful ... and I agree. But the question is, whether that beauty is worth the hassle of the backwards incompatibility and the proposed transition-strategies over the course of *many* years. That's a lot of complication, just to buy some beauty. IFoo is an interface and an interface is at it's core a specification. Lot's of things can be done with this specification: validation, documentation, inspection ... and also lookup and adaptation. For us, adaptation and lookup are the most important uses, but it's not in the very nature of an interface and somebody without zope-knowledge does not neccessarly have that same world view. So it may be convenient to make interfaces callable and return adapters/utilitys and it sure looks nice and requires little typing and all that - but in fact it's a quite zope-ish world view. Wasn't it the main motivation to get rid of the need to having to import and use zope.component whenever we use multi-adaptation or utilitys? So what's so bad about adding methods to interfaces? That meets the original motivation. And it leaves the interface as it's core as a specification and it makes it more clear, what the code does with the interface, instead of imposing our adapters and utilities are the most important thing about interfaces attitude onto it. Also, it doesn't mix adapters and utilities conceptually. There is one method to get me a new instance for the interface and the given parameters and another method to get me some singleton/utility. IFoo.instance(x, y) IFoo.instance(x) IFoo.instance() or with less typing IFoo.new(x, y) ... and IFoo.utility() or IFoo.get() or IFoo.single() ... or some other color ... Maybe we want another method, to return the factory without automatically calling it: IFoo.factory(x, y) ... So we could deprecate the interface-calling functionality and just leave it as it is - this way we do not have to worry about year long transitions and confusion everywhere. This is also in line with IFoo.isProvidedBy(x) and the like. OK - just a few thougths from an observer and zope-user. Regards, Matthias ___ 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] implementing zope.component 4.0
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 IFoo.utility(). Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
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* actually symmetric with registration. * deprecate a non-explicit default such as IFoo(a, default), require IFoo(a, default=default) While this short spelling of component lookup is attractive and sensible for Zopistas, I wonder if it ever really was the best idea. When a developer encounters the IFoo() pattern for the first time, what is he/she going to type into a search engine to find out what it means? I can't think of any search phrase that is likely to give a good answer. When he can't Google, a maintenance developer with no prior ZCA exposure literally sees IFoo() (without any args) is going to find the definition for IFoo and it will be a class. He will believe that calling it will give him back an instance. This is just consistent with all prior experience he has if he's a Python programmer. Furthermore he'll believe he owns the resulting object, because normal classes are always constructors that create a new object. It just can't be obvious to him that IFoo() will almost always return some shared object (a utility) that isn't an instance of the class defined by the IFoo definition. And if a developer is doing maintenance work, he can't afford to track down the docs and become enraptured by the world we create where this isn't the case. JQuery has a similar issue, but because JQuery is a smaller framework, the JQuery folks simply put that info right near the top of their documentation. I'm not sure we can do that quite as effectively. For an alternate spelling, consider what happens when component lookup fails: you get a ComponentLookupError. Lookup is interesting. It doesn't yet have any meaning in zope.interface, so I think using a method named lookup() would make code more comprehensible. You would use it like this: IFoo.lookup(a) SomeAdapter instance at ... IFoo.lookup(a, b) SomeMultiAdapter instance at ... IFoo.lookup(c) Traceback... ComponentLookupError(...) IFoo.lookup(c, default='missing') 'missing' IMyUtility.lookup() MyUtility instance at ... When developers encounter this for the first time, they might type zope.interface lookup in a search engine. That phrase has a reasonable chance of hitting good documentation. What do you think? + 1 with the following caveat: I think that method name should probably be adapt; lookup should maybe be a separate method reserved for passing bare interfaces rather than objects which implement interfaces, e.g: IFoo.lookup(IBar) class FooBarAdapter This would be consistent with the nomenclature in the current zope.interface AdapterRegistry API. If it would help to change the resulting error message to adaptation error when .adapt is called, e.g.: IFoo.adapt(c, default='missing') Traceback... AdaptationError(...) That would be possible too obviously through the magic of subclassing. I think adding methods to the registry object with the same names but slightly different signatures would go hand in hand with such a change: class Components(...): def lookup(self, required, *provided, name=''): ... def adapt(self, required, *provided, name=''): ... sm = getSiteManager() sm.lookup(IFoo, IBar) sm.adapt(IFoo, bar) - 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] implementing zope.component 4.0
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; lookup should maybe be a separate method reserved for passing bare interfaces rather than objects which implement interfaces, e.g: ... 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 lookup style behavior belongs, IMO, as well as other helpers. See below for examples. 2) As argued before, I think that adapt is an ok name for a single object, but becomes a bad name once you have multiadapters in the mix. I would prefer one of the options Matthias Lehmann proposed (new for instance). 3) I also think that utility is a bad name. Is singleton two letters too long? If it is, I mind utility less than I mind adapter. IFoo.new(a, b) # finds and returns result of call IFoo.new.lookup(IA, IB) # finds and returns callable IFoo.new.find(IA, IB) # get all registration information IFoo.new.find_stack(IA, IB) # get an iterable of the stack all registration information for each registration for those two interfaces IFoo.singleton() # finds and returns item IFoo.singleton(name='baz') # finds and returns item IFoo.singleton.lookup(name='baz') # same result in this case IFoo.singleton.find(name='baz') # get all registration information Side, but related point: I wonder if there is value in the ability to spell IFoo.singleton(a) # where a is a required object to the registration. This would make utility registrations more powerful in a way that some people seem to have been missing. It also makes things parallel with creation. Gary ___ 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] implementing zope.component 4.0
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 default: IFoo(default=bar) I disagree with this. More below. [snip] 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 happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. I still don't see why that isn't an implementation detail. How we get an IFoo doesn't concern us when we're calling it, as long as we get an IFoo? Even with adaptation a singleton could be returned; it's just the implementation of such would be different. The people I know are involved in both registration and usage of these things. If we take Marius' pattern, registring a singleton directly would simply be a shortcut API for registring a factory for utilities. (Utility factories would make it easier to implement local utilities that aren't ZODB-backed...) Make those factories that do not take arguments. That's the use case for IFoo(). That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. What is this valuable semantic? Marius said he has had a use case. It sounds like you gave one above. [snip] (To be complete, I am in favor of ditching subscription adapters in favor of other mechanisms related to named singleton lookups.) I really need to think through subscription adapters; I haven't done any analysis about those. 2) The term utility is another barrier to understandability. They are singletons. Explaining them as such is a well, why didn't you say so experience. Another way to explain utilities is that getting a utility is a lot like importing something in Python, except that what is imported is pluggable and the required interface is specified explicitly. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. import by interface to me sounds like it'd clarify matters for more Python programmers. Singleton has all kinds of design pattern connotations that don't really apply here. Moreover, I think that some of the use cases that Marius referred to for underpowered utilities coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. I don't understand. Could you rephrase? Right now you can only look up a utility with a desired output, and optional name. Is it useful to also be able to pass in a context of objects for the lookup (the required values in the underlying implementation)? Features off the table for now --- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. It seems to me that this, along with the documentation call that Chris gave, is a much more valuable immediate effort. One of the biggest complaints I heard was with debugging. I've spent some thought on the debugging story, and have some APIs sketched out in my experiments--it was one of the first things I worked on. To do it cleanly (the way I envision) would require some work, but a first cut wouldn't be too bad. Hm, I disagree about what's more valuable. Sure; we have different perspectives on who we are aiming for. You have said you are not aiming for new/non-expert users, at least in this round. In contrast, they are my primary clients. Gary ___ 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] implementing zope.component 4.0
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 lookup style behavior belongs, IMO, as well as other helpers. See below for examples. 2) As argued before, I think that adapt is an ok name for a single object, but becomes a bad name once you have multiadapters in the mix. I would prefer one of the options Matthias Lehmann proposed (new for instance). I have no great problem with multiadapters as long as the analogy is clear enough - this adapter takes two sources... 3) I also think that utility is a bad name. Is singleton two letters too long? If it is, I mind utility less than I mind adapter. I don't understand this. For me a singletons is (sic) a highly specific programming term whereas adapters and utilities, especially in the way we refer to them, are not so domain specific. IFoo.new(a, b) # finds and returns result of call IFoo.new.lookup(IA, IB) # finds and returns callable IFoo.new.find(IA, IB) # get all registration information IFoo.new.find_stack(IA, IB) # get an iterable of the stack all registration information for each registration for those two interfaces IFoo.singleton() # finds and returns item IFoo.singleton(name='baz') # finds and returns item IFoo.singleton.lookup(name='baz') # same result in this case IFoo.singleton.find(name='baz') # get all registration information Interestingly this is starting to look too verbose and java like to me but I'm also not happy with the use of new or singleton. find might be an idea if it could use introspection to gives clues as to what I might actually want to do with my IFoo implementers. Can you give some sample responses? Side, but related point: I wonder if there is value in the ability to spell Could someone please point me in the direction of the definition of this use of spell? Is it short for spell it out? 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] implementing zope.component 4.0
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 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] implementing zope.component 4.0
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 typo above (should be It's just ...); 2. the preposition it used. I meant: Singleton is a bad name. ___ 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] implementing zope.component 4.0
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 introspection of the underlying registry. That's where the lookup style behavior belongs, IMO, as well as other helpers. See below for examples. 2) As argued before, I think that adapt is an ok name for a single object, but becomes a bad name once you have multiadapters in the mix. I would prefer one of the options Matthias Lehmann proposed (new for instance). I have no great problem with multiadapters as long as the analogy is clear enough - this adapter takes two sources... Well, my first issue is that the adapter word is unnecessary by my definitions. 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 the wall (output interface). Is there a common real-world example of this for multiadapters? 3) I also think that utility is a bad name. Is singleton two letters too long? If it is, I mind utility less than I mind adapter. I don't understand this. For me a singletons is (sic) a highly specific programming term whereas adapters and utilities, especially in the way we refer to them, are not so domain specific. Turned around, people know the term singleton and they do not know the terms adapters and utilities. singletons describe the huge majority of how we use these things. It's something less to explain. Making comprehension quicker is very valuable to me. Put yet another way, how are 99+% of our utility usages not singletons? If that's the case, what's the value of having to explain what a utility is? How do you reply when the people you support say, oh, so this is just a singleton, right? That said, and to repeat, I mind adapter more than utility. IFoo.new(a, b) # finds and returns result of call IFoo.new.lookup(IA, IB) # finds and returns callable IFoo.new.find(IA, IB) # get all registration information IFoo.new.find_stack(IA, IB) # get an iterable of the stack all registration information for each registration for those two interfaces IFoo.singleton() # finds and returns item IFoo.singleton(name='baz') # finds and returns item IFoo.singleton.lookup(name='baz') # same result in this case IFoo.singleton.find(name='baz') # get all registration information Interestingly this is starting to look too verbose and java like to me but I'm also not happy with the use of new or singleton. find might be an idea if it could use introspection to gives clues as to what I might actually want to do with my IFoo implementers. Can you give some sample responses? The majority of those were advanced, or debug usage. That's the kind of thing that Chris was talking about, at least in my estimation if not in his :-) . Here's basic usage. I'll use utility since I'm getting more pushback on that one. :-) ``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo) ``IFoo.utility()`` gives you the singleton registered for IFoo. That's the basic idea. It's basically what Shane proposed, with the adapter - new thing (and my squelching of utility - singleton). What if you want to determine how you got the result that you got? You need some additional methods. My proposal was that you put those methods off of ``.new`` and ``.utility``. You could also make other methods (or objects) off the interface. In my experiments, I have the following debug and utility/advanced methods. You would typically only look at these if you were trying to figure out what was going on, or if you were doing something tricky. .lookup (what Chris proposed) .lookup_all (also based on the registry call of the same method) .find (get registration information--that is, value, required, provided, name--for the same input as lookup) .find_all (get registration information dictionary for the same input as lookup_all) .find_stack (returns an iterable of registrations, beginning with the one that would have been chosen, and following with the registrations that were masked by that one.) .__iter__ (iterate registrations for output interface) .find_for_value (returns an iterable of registrations for output that have the given value) These are also on the underlying shared registries, with similar meaning. Side, but related point: I wonder if there is value in the ability to spell Could someone please point me in the direction of the definition of this use of spell? Is it short for spell it out? A spelling in this sense is a specific API for an idea. I was asking about the *ability* to spell--whether this kind of usage was interesting. Gary
Re: [Zope-dev] implementing zope.component 4.0
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 a bad name. :-) To clarify because of 1. the typo above (should be It's just ...); 2. the preposition it used. I meant: Singleton is a bad name. I've given my reasons (the most recent attempt was to Charlie Clark). You give yours. :-) Gary ___ 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] implementing zope.component 4.0
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 the case, what's the value of having to explain what a utility is? There is nothing to explain. Utility is something useful that helps you accomplish a task. Which task? Well, the one you just looked a utility for. :-) Zvezdan ___ 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] implementing zope.component 4.0
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 programmers know the term singleton. Though it's not unusual for there to be exactly one instance of a class in a process, it's pretty unusual to think about that as a valuable aspect of a class. Which for the traditional definition of singleton, it very much is. -1 for calling utilities singletons, since that has nothing to do with their usage. +1 for calling them utilities, since that has everything to do with how they're used. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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] implementing zope.component 4.0
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 the wall (output interface). Is there a common real-world example of this for multiadapters? I have a Roku player (great device, BTW). It streams video from Netflix and other sources. It takes two inputs (network and power) and produces one output (a video signal). I could call the device a multi-adapter, but the power input is so simple and reliable that I forget about it. Most of the time I think of the Roku player as a simple adapter from Internet packets to a video signal, but electrically, it's definitely a multi-adapter. Note that the network signal for a Roku player varies wildly, while the power is either ~110VAC or ~220VAC. Multi-adaptation works best when it has similar characteristics, I think. It's safe to allow one of the inputs to multi-adaptation to vary a lot, but to keep developers sane, the rest of the inputs should be more predictable. I think getMultiAdapter((context, request)) is OK because most web sites have only one or two request types. Turned around, people know the term singleton and they do not know the terms adapters and utilities. singletons describe the huge majority of how we use these things. It's something less to explain. Making comprehension quicker is very valuable to me. Do you intend to change the API names in zope.component, then? For example, getUtility - getSingleton? That might be possible, but no one has suggested it before (AFAIK), and I think it's implied by your suggestion. ``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo) Using new for a name could be a problem for Jython and IronPython users, since new is a keyword in other languages. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] adapter vs factory Re: implementing zope.component 4.0
On Nov 30, 2009, at 5:14 PM, Lennart Regebro wrote: On Mon, Nov 30, 2009 at 22:40, Gary Poster gary.pos...@gmail.com 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 the wall (output interface). Is there a common real-world example of this for multiadapters? Yup. http://www.amazon.co.uk/Scart-Adapter-Switchable-Plug-Socket/dp/B00077DC6A Audio + Video in: SCART out. :) heh. And Shane's example was more commonplace. I still think this is unusual, or in Shane's example, not something that people think of as a multiadapter. But as said, to Fred, point partly taken. :-) [snip utility/singleton] That said, and to repeat, I mind adapter more than utility. But adapter is really what it is. OK, Multiadapters are evidently complicated... But is it really so complicated that we should throw away the commonly accepted GoF for what clearly are adapters? How is it less confusing to call IFoo.instance(x,y) than IFoo.adapt(x,y) or even IFoo(x,y)? I am very much in favor of IFoo(x, y). That makes me very happy. It looks mostly like you are instantiating a class, except that it looks a bit funny: in my view, it is a reasonably good leaky abstraction for what is going on. People also like the compactness of the spelling, in my discussions. They also remember it very well, even over long periods of not using the API. This is a big deal. Backwards compatibility is the problem. I need to go have a life. :-) Talk to you all tomorrow. Gary ___ 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] implementing zope.component 4.0
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, but the impact is less big. In any case, I would like to deprecate non-explicit keywords parameters for 'default' and 'name'. I think these would be a reasonable compromise. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] implementing zope.component 4.0
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 people, like Jim, to comment before finalizing the decision. Good point. We'll give it some more time. 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 with registration. +1 * deprecate a non-explicit default such as IFoo(a, default), require IFoo(a, default=default) +0 * do the other stuff (name, utility lookups, etc) +1 * this will be a zope.component 3.x release. Or we could even call it 4.0. I'd say 4.0 is more appropriate. This gives us some room to have further 3.x releases in-between/afterwards. * we can stick with this for quite a while. * in some years time, see about allowing IFoo(a, b) for multi adaptation. By that time people will have updated their code to use explicit defaults everywhere. +0 * then deprecate IFoo((a, b)) in favor of IFoo(a, b) * we can then allow tuple adaptation again. :) +0 This seems like a more reasonable compromise to me. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] implementing zope.component 4.0
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 a plug (required interface) so it can plugged in to the wall (output interface). Is there a common real-world example of this for multiadapters? In the plumbing area, The mixing valve adapt a cold water entry and a warm water entry to a single water output at your preferred temperature ___ 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 )
