Re: [Zope-dev] singleton vs. utility (was Re: implementing zope.component 4.0)
On Tue, Dec 1, 2009 at 01:16, Gary Poster gary.pos...@gmail.com wrote: I don't love singleton. I think it is better than utility. I agree at least that it probably isn't better enough to introduce confusion. I'd be more insistent on singleton, or finding a better term than either of them, if this were a fresh API. I wonder if the best isn't to make the documentation clearly say Utilties are singleton components that can be looked up per interface. -- 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: 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 put my 2 Cents in: Back when I started with Zope 3, the term adapter was really not very understandable. So the explanation: a factory to produce an object that provides the interface makes it really a lot more clearer. 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. Exactly. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] Need help
I have to use a logging framework in my zope product. The logging framework makes it mandatory to use the same object instance to fire various logging calls (like log start, log end). I want to store the object instance somewhere so that I can use it from any module in my zope product. I tried to store it in context._ProductContext__app. There are two patch classes of httprequest and httpresponse inside which the context is not available. How do I do this in Zope-2.8.8 Thanks Roopesh ___ 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 Mon Nov 30 12:00:00 2009 UTC to Tue Dec 1 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: Mon Nov 30 20:38:25 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013113.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Nov 30 20:40:25 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013114.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Nov 30 20:42:25 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013115.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Nov 30 20:44:26 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013116.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Nov 30 20:46:26 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013117.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Nov 30 20:48:26 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013118.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] Object schema field validation
Hi, On 11/29/2009 12:02 PM, Markus Kemmerling wrote: I stumbled upon a problem with Object schema field validation. The problem occurs, e.g., if the the Object field's schema itself contains a Choice field with a dynamically computed vocabulary. For the latter to validate correctly the field must be bound to the instance. But the Object field validation code in zope.schema._fields._validate_fields validates the attributes of the Object field instance without binding them first: def _validate_fields(schema, value, errors=None): ... try: attribute = schema[name] if IField.providedBy(attribute): # validate attributes that are fields attribute.validate(getattr(value, name)) except ValidationError, error: ... Replacing the line attribute.validate(getattr(value, name)) with field = attribute.bind(value) field.validate(getattr(value, name)) fixes the problem. Looks like a bug to me. Yeah, sounds like it. Would you mind reporting this to the bug tracker and put the bug number into this thread so people can later find it in the archive? Thanks and kind regards, Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · 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
Shane Hathaway wrote: [a lookup method instead of calling the interface] What do you think? Two objections to a method lookup: * I do like the notion of casting an object with an interface. We can at least interpret single adaptation that way. * doing a call better makes this lookup mechanism disappear into the language But I could live with 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
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? It's a good question. Plugging a power cord in on both ends? :) Slightly more seriously, a lego brick connecting to multiple other bricks? But that isn't a good enough answer to that question. 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. I don't like the word singleton very much either. Singleton in the Design Patterns book has a very particular implementation that is criticized by a lot of developers and in particular that particular pattern is very uncommon in the Python world (people just use globals). I think introducing the term would pull in all that baggage to a newcomer. Just type in 'singleton' in Google and you'll get the wikipedia definition: In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. Utility classes are *not* restricted to a single instantiation. Now we can argue successfully that's an extension of the singleton principle, but then we've lost a lot of people already who thought they knew (or went to lookup) what the word singleton means. 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: Tres Seaver wrote: [snip] The root of the disagreement here is that you seem to want the *caller* to care about something which is important only to the person who *registers* the thing being looked up. From the caller's perspective, the call site needs an object 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. I think this more often has to do with knowing whether an object should be treated as if it's immutable or not. Often you construct objects and when they're done you only consult them and don't manipulate them anymore. The traditional world view works best for objects treated as immutable - you can apply the flyweight pattern (caching) more easily for instance. We call non-factories utilities and we call factories adapters. So the caller *already* needs to make a distinction between the two. That's a good point. Let me generalize a bit here below. Adaptation in ZCA is a combination of Design Pattern's abstract factory pattern and the adapter pattern. A utility is something you get back by calling a similar abstract function, but you get back an instance that was already registered previously. Marius and Gary discussed introducing more symmetry. Here is the symmetrical picture as I see it: * abstract factory called on an object (adaptation) In: one ore more instances providing some interfaces, the requested interface Out: a new instance created by a factory that provides the requested interface * abstract instance retrieval (utility lookup) In: the requested interface Out: a previously registered instance that provides the requested interface. * abstract factory not called on an object (utility factory, null-adaptation) In: the requested interface Out: a new instance created by a factory that provides the requested interface * abstract instance retrieval for an object (utility associated with an instance, adapting to an existing instance) In: one or more instances providing some interfaces, the requested interface Out: a previously registered instance for that object that provides the requested interface There is also the issue of connections: * an adapter typically has a connection to the adapted object. It's not required, however. This is possible because it gets instantiated with the adapted objects as arguments. * a utility never has a connection. That's because it already got instantiated long before the lookup takes place. Whether you see the existence of a connection as essential probably influences whether you prefer the term adapter or utility in the two latter cases. Here I've looked at the inside of adapters and utilities, and I've also looked at how these things get created. Now back to the traditional perspective, which I think while not incontrovertible is still extremely valuable. I like the pattern where the caller shouldn't need to know *how* the returned object is created. This suggests unifying utility and adapter lookup. So: IFoo.instance() IFoo.instance(a) IFoo.instance(a, b) Give me an instance of IFoo (given these objects). Underneath it could go instantiate IFoo right then and there, possibly passing the arguments to the factory, or it could retrieve an existing IFoo from some registry somewhere. In design patterns terms, a factory could *always* be called. It's just that sometimes it turns around and returns a previously registered instance. (if we are going for a method on an interface, it's clear that instance is better than new, as new implies a new instance while instance doesn't imply this. Given it's just one method I'd still be inclined to just call the interface directly) 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Hi there, I'd like to summarize the options I've seen appear in the discussion so far. We have the following options: 1) introduce a new method, such as instance() or lookup() on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility. 2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility. 3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a multi argument approach. 4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the default argument. We'd need to introduce multiple modes to selectively upgrade. I'm in favor of calling the interface. I'm also in favor of unifying adapter and utility lookup. On the back end, I'm also in favor of allowing utility creation by factory (or null adaptation) and allowing instance lookup for instances (contextual utility lookup or adaptation to an instance). I think four ways to retrieve an object of the right interface (combining factory/registered instance and lookup globally/lookup for an instance) is a good argument *against* distinguishing between creation strategies or connection to adapted object or not in the API. If I look up a utility I wouldn't want to care whether it happened to be a previously registered instance or a factory created one. If I look up an adapter I wouldn't care whether it happened to be a previously registered instance either. In fact, returning a previously registered instance can be very well implemented using a factory. (In fact, this suggests to me we should actually explore implementing instance registration in terms of special factories.) 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] z3c.recipe.i18n tests fail
Hi,
the tests fail with the following error:
Running zope.testing.testrunner.layer.UnitTests tests:
Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
File /Users/zagy/development/python/lib/python2.6/unittest.py, line
270, in run
self.setUp()
File
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line 2289, in setUp
self._dt_setUp(test)
File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
File
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line 464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'
I actually have no idea why this is happening. Anybody got a clue?
Regards,
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · 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
Martijn Faassen wrote: I don't like the word singleton very much either. Singleton in the Design Patterns book has a very particular implementation that is criticized by a lot of developers and in particular that particular pattern is very uncommon in the Python world (people just use globals). I think introducing the term would pull in all that baggage to a newcomer. Just type in 'singleton' in Google and you'll get the wikipedia definition: In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. Utility classes are *not* restricted to a single instantiation. Now we can argue successfully that's an extension of the singleton principle, but then we've lost a lot of people already who thought they knew (or went to lookup) what the word singleton means. For the record, I normally use the singleton analogy to explain unnamed global utilities. Perhaps that's bad, though I find it works pretty well. It'd probably be more accurate to use the terms you did, an extension of the singleton principle, but as you say, it just adds more complexity. To me, the Singleton pattern says, each time you ask for this, you get the same object. That's a little bit different from this class can only be instantiated once. I think the important part of the design pattern is the shared instance (e.g. to conserve resources or to implement some kind of shared counting/tracking), not the restrictions on instantiation. I'm certainly -1 on using the term in the ZCA. I think changing our nomenclature would be terrible for the same reasons I think changing (as opposed to extending/improving) our API would be terrible. Utilities are in one way a more specific concept (due to the lookup semantics) and in another way a more generic concept (since named utilities can be used to implement a registry of homogenous objects). 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
Martin Aspeli wrote: For the record, I normally use the singleton analogy to explain unnamed global utilities. Perhaps that's bad, though I find it works pretty well. It'd probably be more accurate to use the terms you did, an extension of the singleton principle, but as you say, it just adds more complexity. To me, the Singleton pattern says, each time you ask for this, you get the same object. That's a little bit different from this class can only be instantiated once. I think the important part of the design pattern is the shared instance (e.g. to conserve resources or to implement some kind of shared counting/tracking), not the restrictions on instantiation. I'm certainly -1 on using the term in the ZCA. I think changing our nomenclature would be terrible for the same reasons I think changing (as opposed to extending/improving) our API would be terrible. Utilities are in one way a more specific concept (due to the lookup semantics) and in another way a more generic concept (since named utilities can be used to implement a registry of homogenous objects). To me the fact that an object is a singleton or a factory is orthogonal to the registry stuff. Why can't utilities be factories too that simply return themselves when being called? Then being a singleton or not would be in the responsibility of the registered object (class, factory, singleton) and the ZCA would not need to know. What am I missing (except bbb)? ___ 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Martijn Faassen wrote: Hi there, I'd like to summarize the options I've seen appear in the discussion so far. We have the following options: 1) introduce a new method, such as instance() or lookup() on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility. 2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility. 3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a multi argument approach. 4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the default argument. We'd need to introduce multiple modes to selectively upgrade. I'm in favor of calling the interface. I'm also in favor of unifying adapter and utility lookup. On the back end, I'm also in favor of allowing utility creation by factory (or null adaptation) and allowing instance lookup for instances (contextual utility lookup or adaptation to an instance). I think four ways to retrieve an object of the right interface (combining factory/registered instance and lookup globally/lookup for an instance) is a good argument *against* distinguishing between creation strategies or connection to adapted object or not in the API. If I look up a utility I wouldn't want to care whether it happened to be a previously registered instance or a factory created one. If I look up an adapter I wouldn't care whether it happened to be a previously registered instance either. In fact, returning a previously registered instance can be very well implemented using a factory. (In fact, this suggests to me we should actually explore implementing instance registration in terms of special factories.) I am also in favor of unifying adapter and utility lookup. Or at least creating a more normalized API. On the syntax of the change: I am more or less somewhere between -0 and +0 on the idea of presenting a unified API as methods of interfaces (call or non-call). While I don't think this idea is the worst idea in the world and it might be better than the current global API, I don't think we should *only* do this; similar changes should be made to the registry itself. Code that uses the global API needs to do a registry lookup for each usage, so it's slower than code which doesn't. If interface methods become available to unify adapter and utility lookup, the same sorts of methods should be added to the registry itself for performance-sensitive code. I also believe that code that locates a registry explicitly and calls lookup methods on it is easier to understand for the maintenance programmer than is an equivalent global API. On the semantics of the change: Personally I think that it's a fantasy to believe that the difference between an object created via a factory on-demand and an object simply returned should *never* matter to a caller. You may not want the caller to need to care, and it may be inconvenient to take into account circumstances where the caller needs to care. But because this is Python, the caller still often does need to care. The only circumstance where a caller would *never* need to care would be when the object returned could be guaranteed to *never ever* have any methods called on it that weren't part of the interface defined by the interface being looked up. If we want this, we should probably just be using Java. I am extremely uncomfortable with any situation where: class IFoo(Interface): pass IFoo() ... does not result in any factory invocation. I hope it's obvious why this is the case. The current global API has a modicum kindness for maintenance developers because we *haven't* unified adapter and utility lookup in such a way. They stand a shot at understanding that the result of getUtility usually has lifetime A and the result of getAdapter/getMultiAdapter has lifetime B. If we take out this safety belt, I'd lean towards more explicitness rather than less: let the caller call the result of the lookup. - 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 Tue, Dec 1, 2009 at 3:38 PM, Martin Aspeli optilude+li...@gmail.com wrote: I'm certainly -1 on using the term in the ZCA. I think changing our nomenclature would be terrible for the same reasons I think changing (as opposed to extending/improving) our API would be terrible. Utilities are in one way a more specific concept (due to the lookup semantics) and in another way a more generic concept (since named utilities can be used to implement a registry of homogenous objects). And once you mix in location dependent utilities aka. local utilities you lost almost all of the singleton idea. Now suddenly you can get a different instance depending on the execution context, which might not be obvious from the location of the lookup in the code. You still get an instance conforming to an interface, though. So in a sense this is indeed more like a null-adapter. All adapters or utilities have the global process or execution context as an implied dimension, even it's bad practice to rely on that hidden dimension too much, we do that all the time with thread globals like the database connection. 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
Joachim König wrote: [snip] To me the fact that an object is a singleton or a factory is orthogonal to the registry stuff. Why can't utilities be factories too that simply return themselves when being called? Then being a singleton or not would be in the responsibility of the registered object (class, factory, singleton) and the ZCA would not need to know. What am I missing (except bbb)? I don't think you're missing anything. It's just that others have a different perspective on this than you and me. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
On Dec 1, 2009, at 9:54 AM, Chris McDonough wrote: Martijn Faassen wrote: ... I am also in favor of unifying adapter and utility lookup. Or at least creating a more normalized API. I guess it is no surprise that I am in favor of a normalized API but against the unification. On the syntax of the change: [...] I followed vaguely. This was about unification, correct? On the semantics of the change: Personally I think that it's a fantasy to believe that the difference between an object created via a factory on-demand and an object simply returned should *never* matter to a caller. You may not want the caller to need to care, and it may be inconvenient to take into account circumstances where the caller needs to care. But because this is Python, the caller still often does need to care. Again, no surprise that I agree with this and following. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Martin Aspeli wrote: Can you summarise what you mean by this? The thread is so long... [snip] My brain hurts... examples? [snip] I'm afraid you've lost me. Four ways sounds bad, though. ;-) I've edited down and clarified what I posted earlier. First a statement about the goal of this discussion. The goal of this discussion is to convince people to unify the lookup API. I wouldn't want to make lookup API improvements depend on improvements to zope.component inspired by the discussion below. I'm in favor of exploring that in a separate project, however. * abstract factory called on an object (adaptation) In: the requested interface, one ore more instances Process: look up factory. Call factory with input instances. Out: a new instance that provides requested interface * abstract instance retrieval (utility lookup) In: the requested interface Process: look up instance. Out: a previously registered instance that provides requested interface. * abstract factory not called on an object (utility factory, null-adaptation) In: the requested interface Process: look up factory. Call factory. Out: a new instance that provides the requested interface * abstract instance retrieval for an object (utility associated with an instance, adapting to an existing instance) In: the requested interface, one or more instances. Process: look up instance with input instances as context. Out: a previously registered instance that provides the requested interface The two latter patterns aren't fully supported. All of them could in principle be emulated using the look up factory/call factory pattern. There are two perspectives on distinguishing adapters from utilities. One perspective is: * newly created instance (adapter) versus previously registered instance (utility). This perspective informs the singleton discussion. I'd say a better way to distinguish adapters from utilities (should we wish to do so) is: * arguments into the factory (adapter) versus no arguments into the factory (utility) That's inspired by the notion that adapters tend to have some form of abstract connection to what they adapt, while utilities do not. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote:
Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
File /Users/zagy/development/python/lib/python2.6/unittest.py, line
270, in run
self.setUp()
File
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line 2289, in setUp
self._dt_setUp(test)
File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
File
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line 464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'
Should be fixed now. Yuppie
___
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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Chris McDonough wrote: On the semantics of the change: Personally I think that it's a fantasy to believe that the difference between an object created via a factory on-demand and an object simply returned should *never* matter to a caller. You may not want the caller to need to care, and it may be inconvenient to take into account circumstances where the caller needs to care. But because this is Python, the caller still often does need to care. The only circumstance where a caller would *never* need to care would be when the object returned could be guaranteed to *never ever* have any methods called on it that weren't part of the interface defined by the interface being looked up. If we want this, we should probably just be using Java. I'll retract this. If you want to create a world where callers never need to care about the lifetime of any object returned by a component lookup, you could also return a proxy wrapper around the returned object that only allows for the invocation of the methods defined in the interface looked up. Any other access or invocation would raise an exception. This would make this worldview 100% consistent, completely documentable, and would cause no confusion during use. It would thus remove any logical argument I have against it. I wouldn't be eager to use such a system, but it's totally consistent. - 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
Martijn Faassen wrote: Joachim König wrote: [snip] To me the fact that an object is a singleton or a factory is orthogonal to the registry stuff. Why can't utilities be factories too that simply return themselves when being called? Then being a singleton or not would be in the responsibility of the registered object (class, factory, singleton) and the ZCA would not need to know. What am I missing (except bbb)? I don't think you're missing anything. It's just that others have a different perspective on this than you and me. Clearly, it could. But that's not the way we went. Changing it now would be really damaging, and I'm not sure what would be gained. I can imagine use cases where getting a new instance each time would be useful. I can't say I've ever actually needed it, though. If it's something that can be done without breaking existing code or requiring the rewriting of history on patterns we've encouraged and documented to date, it'd certainly be an interesting option to explore. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
On Tue, Dec 1, 2009 at 14:21, Martijn Faassen faas...@startifact.com wrote: Hi there, I'd like to summarize the options I've seen appear in the discussion so far. We have the following options: 1) introduce a new method, such as instance() or lookup() on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility. 2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility. 3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a multi argument approach. 4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the default argument. We'd need to introduce multiple modes to selectively upgrade. You missed: 5) Call the interface for adaption, and something else for utility lookup, with tuples for multi-adaptation. 6) Call the interface for adaption, and something else for utility lookup, with multiple arguments for multi-adaptation. 7) Do nothing. ;) I'm minus lots for any unification of adapters and utilities. Since a utility does not adapt anything, and adapters do, all they have in common is that they implement an interface. Since in some sense, all objects implement an interface, we have reinvented the object. That's going to confuse the heck out of everyone. It's a very bad idea. If tuple adaption is common, which I doubt, I'm +1 for 2. If tuple adaption is uncommon, I'm +1 for 5. I'm also: -0 for 6 -1 for 7 -lots for the rest If I look up a utility I wouldn't want to care whether it happened to be a previously registered instance or a factory created one. If I look up an adapter I wouldn't care whether it happened to be a previously registered instance either. In fact, returning a previously registered instance can be very well implemented using a factory. (In fact, this suggests to me we should actually explore implementing instance registration in terms of special factories.) Making it less common to have to keep track on when you need factories and not would be a definite benefit. -- 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
On Dec 1, 2009, at 8:21 AM, Martijn Faassen wrote: Hi there, I'd like to summarize the options I've seen appear in the discussion so far. We have the following options: 1) introduce a new method, such as instance() or lookup() on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility. 2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility. 3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a multi argument approach. 4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the default argument. We'd need to introduce multiple modes to selectively upgrade. You are leaving out the variants of 3 and 4 that allow calling the interface to support multiadaptation, but do not unify utilities. My impression is that I am not the only one who is not pleased with the proposed unification of utilities and adaptation. My impression is that we are nearing consensus on the variation of 3 that does not include utilities. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Martijn Faassen wrote: First a statement about the goal of this discussion. The goal of this discussion is to convince people to unify the lookup API. I wouldn't want to make lookup API improvements depend on improvements to zope.component inspired by the discussion below. I'm in favor of exploring that in a separate project, however. +1 * abstract factory called on an object (adaptation) In: the requested interface, one ore more instances Process: look up factory. Call factory with input instances. Out: a new instance that provides requested interface * abstract instance retrieval (utility lookup) In: the requested interface Process: look up instance. Out: a previously registered instance that provides requested interface. * abstract factory not called on an object (utility factory, null-adaptation) In: the requested interface Process: look up factory. Call factory. Out: a new instance that provides the requested interface * abstract instance retrieval for an object (utility associated with an instance, adapting to an existing instance) In: the requested interface, one or more instances. Process: look up instance with input instances as context. Out: a previously registered instance that provides the requested interface The two latter patterns aren't fully supported. All of them could in principle be emulated using the look up factory/call factory pattern. I think the last pattern can be implemented with a custom adapter factory. You'll need custom retrieval code anyway, so there's probably not much more room for abstraction. There are two perspectives on distinguishing adapters from utilities. One perspective is: * newly created instance (adapter) versus previously registered instance (utility). This perspective informs the singleton discussion. I'd say a better way to distinguish adapters from utilities (should we wish to do so) is: * arguments into the factory (adapter) versus no arguments into the factory (utility) That's inspired by the notion that adapters tend to have some form of abstract connection to what they adapt, while utilities do not. This is certainly true, but does that really inform how we use these things? To me, I use unnamed utilities for: * singletons (as in, one implementation) * strategies (as in, I look up some configuration for an algorithm by asking the CA for an object providing a particular interface) I use named utilities for: * registries of homogeneous objects (to avoid implementing my own registry) I use adapters for: * the adapter pattern (my code expects an IFoo; the client code can write an adapter factory to get me one from whatever context it passes in) * customisation/specialisation (I look up an adapter to fulfil some policy, allowing it to be overridden with more specific adapters) And a few other variations (such as the retrieve object use case, but that's very rare and has largely been an implementation detail). I don't think of these in terms of how many arguments the component needs. I think of them in terms of various software patterns. And to me, an adapter provides the ability to work with different aspects of an object (adapting it to different interfaces) whilst utilities provides a way to get the current implementation of a particular service or policy. I'm very much for consistent APIs, and if we can simplify the registry implementation with more shared code, that'd be great. I'm just really worried that we try to simplify by replacing two concepts we've spent ages teaching people, with a single concept that is even more abstract and used in even more different ways for even more purposes. You start having to use lots of words to disambiguate (named multi argument factory component == a view). I don't think we win there. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Chris McDonough wrote: Personally I think that it's a fantasy to believe that the difference between an object created via a factory on-demand and an object simply returned should *never* matter to a caller. You may not want the caller to need to care, and it may be inconvenient to take into account circumstances where the caller needs to care. But because this is Python, the caller still often does need to care. The only circumstance where a caller would *never* need to care would be when the object returned could be guaranteed to *never ever* have any methods called on it that weren't part of the interface defined by the interface being looked up. If we want this, we should probably just be using Java. I think it's okay for us to say: if you call a method on something that you retrieved by interface that isn't actually specified to be on that interface, you're on your own. It may work, but it's not specified to work by the system you're using. I'm not sure why lifetime issues are considered so important here. Of course they sometimes matter. But we use ORMs all the time. We create traversal hierarchies on the fly all the time. What's different in this case? If I want to index an object, do I care whether the catalog was just created on the fly and it's talking to a relational database? I think you're arguing that because abstractions are sometimes leaky (lifetime issues) we shouldn't have this abstraction at all. Why is the leakiness so important here? [snip] The current global API has a modicum kindness for maintenance developers because we *haven't* unified adapter and utility lookup in such a way. They stand a shot at understanding that the result of getUtility usually has lifetime A and the result of getAdapter/getMultiAdapter has lifetime B. If we take out this safety belt, I'd lean towards more explicitness rather than less: let the caller call the result of the lookup. I think there are two centers of attraction for unification: * everything is a factory. If I want to look up an instance, I look up a factory that returns me the same instance all the time. I.e. IFoo() and IFoo(a) * everything is an instance. If I want to call a factory, I look up an instance that is a factory, and call it. I.e. IFoo.lookup() and IFoo.lookup(a)(a) zope.component presents a compromise between those positions. The advantage I see of unifying towards factories is a less verbose API for common operations than an explicit API would have. If you take the utilities come from a factory approach, this would suggest an API like this (on Interface): def __call__(self, arg=()): if not isinstance(arg, tuple): arg = (arg,) return self.factory(arg)(*arg) # low level def factory(self, arg=()): return registry.lookup(from_=arg, to=self) The drawback is that while you *can* register utilities as non-factories and look them up, you'd do it through 'factory', as the real way to look up utilities would be to call a factory. If you take the utilities are registered instances, that would suggest an API like this: # convenience def __call__(self, arg=()): if not isinstance(arg, tuple): arg = (arg,) return self.lookup(arg)(*arg) def lookup(self, arg=()): return registry.lookup(from_=arg, to=self) You'd register utilities as instances directly and look them up using lookup(). The convenience method still works for adapters. The drawback is that IFoo() would result in IFoo.lookup()(), and calling the utility would make no sense. The implementations are the same, but the semantics are quite different. :) 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: Clearly, it could. But that's not the way we went. Changing it now would be really damaging, and I'm not sure what would be gained. I can imagine use cases where getting a new instance each time would be useful. But that is under the full controll of the __call__ of the utility, it could return whatever it wants, as long as what it returns implements the requested interface of course ( imagine a pool of utilities implementing the interface, some being busy) If you'd like to check (as a user of the ZCA) if you got a singleton for a utility, then compare the lookup() against the utility returned, e.g. __call__ returned self. The distinction between utility and adapter only burdens the ZCA with no gain. The only reason for ZCA to know about it today is to decide if to return the registered object or to call it. And a lot of discussion is necessary to explain the difference. ___ 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Chris McDonough wrote: I am more or less somewhere between -0 and +0 That is a high degree of precision. Maybe we need to start thinking of our voting system as a Decimal instead of an int? 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Hey, Chris McDonough wrote: [snip] If you want to create a world where callers never need to care about the lifetime of any object returned by a component lookup, you could also return a proxy wrapper around the returned object that only allows for the invocation of the methods defined in the interface looked up. Any other access or invocation would raise an exception. This would make this worldview 100% consistent, completely documentable, and would cause no confusion during use. It would thus remove any logical argument I have against it. I wouldn't be eager to use such a system, but it's totally consistent. In the Python world interfaces aren't enforced on the language level. But we all know that the programmer better beware and follow the implicit API anyway. With zope.interface, we have a tool to make that implicit interface explicit. Static type advocates argue that if you actually shouldn't cheat anyway, you should have the language help you in verifying that what you're doing is correct. Dynamic type advocates argue that the developer overhead of typical statically typed languages is so big that we'd rather have a bit more danger. And sometimes being able to cheat and get away with it is darn convenient. We happen to be using a dynamically typed language. I don't understand why this particular situation is so unique that this would require a proxy that raises exceptions. If you follow that reasoning, you could just as well say the only sane way to use methods in Python is to require proxies that raise exceptions around method arguments if the input doesn't provide the right interface. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Am 01.12.2009, 17:08 Uhr, schrieb Lennart Regebro rege...@gmail.com: I'm +1 for 5. wot he said x 10 :-) The video + audio to scart example struck me last night and providing expressive(?) examples of this to match so that one is less easily caught by tuples as arguments is a doddle. cables = (audio, video) connector = IScart.adapt(cables, HDTV) Assuming I haven't got totally the wrong end of the stick this shouldn't confuse anyone. Now, do we have any similar simple but expressive analogy for utilities? Soap dispensers? ISoapDispenser.utility().dispense() # agained, spelled out for clarity seeing as that's all the utility does. I hope my analogies aren't too far off the mark. Helps me a lot not to think about what's really going on. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
On Tue, Dec 1, 2009 at 16:28, Martijn Faassen faas...@startifact.com wrote: * abstract factory not called on an object (utility factory, null-adaptation) In: the requested interface Process: look up factory. Call factory. Out: a new instance that provides the requested interface When would you need this? As I understand it, the only difference from the normal utility lookup is that you don't get singletons. IMO that breaks the concept of what a utility is, so null-adaption is a better name for that, but that still means you adapt nothing, so it's not an adapter either. :-) * abstract instance retrieval for an object (utility associated with an instance, adapting to an existing instance) In: the requested interface, one or more instances. Process: look up instance with input instances as context. Out: a previously registered instance that provides the requested interface Hmm. Singleton adapters, in other words. I can see that as useful, sure. -- 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Gary Poster wrote: You are leaving out the variants of 3 and 4 that allow calling the interface to support multiadaptation, but do not unify utilities. True, my mistake. Lennart pointed that out too just now. My impression is that I am not the only one who is not pleased with the proposed unification of utilities and adaptation. I've tried to analyze why that might be so elsewhere. There are three perspectives that I can see: * everything registered is really a factory. Returning a utility just requires registering a special factory. * everything registered is really an instance. Calling an adapter is just looking up an instance and then calling it. * we have two kinds of things registered, instances and factories. zope.component does that today. My impression is that we are nearing consensus on the variation of 3 that does not include utilities. I could live with that, as long as we had a way to look up utilities on the interface too. 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
Joachim König wrote: Martin Aspeli wrote: Clearly, it could. But that's not the way we went. Changing it now would be really damaging, and I'm not sure what would be gained. I can imagine use cases where getting a new instance each time would be useful. But that is under the full controll of the __call__ of the utility, it could return whatever it wants, as long as what it returns implements the requested interface of course ( imagine a pool of utilities implementing the interface, some being busy) I wouldn't want to force everyone to implement def __call__(self): return self Since this is the most common (and current) use case. And ignoring BBB is not an option. :) Nor would I want some separation of factory and object where everyone had to implement both. If you'd like to check (as a user of the ZCA) if you got a singleton for a utility, then compare the lookup() against the utility returned, e.g. __call__ returned self. You wouldn't. The distinction between utility and adapter only burdens the ZCA with no gain. The only reason for ZCA to know about it today is to decide if to return the registered object or to call it. And a lot of discussion is necessary to explain the difference. I disagree. I think it may burden the internal implementation of the ZCA. I don't think it that's the correct perspective, though. I think that logically, these are two different concepts that meet two different sets of use cases. I think there'd be *more* documentation required to explain how one super-general concept stretches to a dozen different use cases, than to explain how two concepts stretch to half a dozen each in two broad categories. See my reply to Martijn for more detail. 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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, I'd like to summarize the options I've seen appear in the discussion so far. We have the following options: 1) introduce a new method, such as instance() or lookup() on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility. 2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility. 3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a multi argument approach. 4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the default argument. We'd need to introduce multiple modes to selectively upgrade. I'm in favor of calling the interface. I'm also in favor of unifying adapter and utility lookup. +1 to both. I think #3 is the best overall compromise, perhaps eventually migrating to #4 after all use of positional default has faded away. Making tuple adapter lookup use the non-sugar spelling seems a pretty low cost. On the back end, I'm also in favor of allowing utility creation by factory (or null adaptation) and allowing instance lookup for instances (contextual utility lookup or adaptation to an instance). I think four ways to retrieve an object of the right interface (combining factory/registered instance and lookup globally/lookup for an instance) is a good argument *against* distinguishing between creation strategies or connection to adapted object or not in the API. One easy way to handle this seamlessly is to check the registered object: if it implements (rather than provides) the interface, then call it, otherwise just return it. Folks who use factories which don't declare what they implement would need to adjust if we adopt this approach. 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 iEYEARECAAYFAksVSGwACgkQ+gerLs4ltQ53awCff+U4Pf836NucmWnLCCrvrwul kC0An3UG6NT51numMPPh78DCqSK9HrJy =tq4A -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] Need help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roopesh P Raj wrote: I have to use a logging framework in my zope product. The logging framework makes it mandatory to use the same object instance to fire various logging calls (like log start, log end). I want to store the object instance somewhere so that I can use it from any module in my zope product. I disagree on the need to use a global: you should just be able to call 'logging.getLogger(yourapp)' and use the instance which comes back. 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 iEYEARECAAYFAksVSzgACgkQ+gerLs4ltQ7mJQCfT8l37V7RWX8MvmtpklHw2FrR TkMAn3azqJsj0WxcROprl1s3FqEnn2EC =/fpV -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] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0
Martijn Faassen wrote: Chris McDonough wrote: Personally I think that it's a fantasy to believe that the difference between an object created via a factory on-demand and an object simply returned should *never* matter to a caller. You may not want the caller to need to care, and it may be inconvenient to take into account circumstances where the caller needs to care. But because this is Python, the caller still often does need to care. The only circumstance where a caller would *never* need to care would be when the object returned could be guaranteed to *never ever* have any methods called on it that weren't part of the interface defined by the interface being looked up. If we want this, we should probably just be using Java. I think it's okay for us to say: if you call a method on something that you retrieved by interface that isn't actually specified to be on that interface, you're on your own. It may work, but it's not specified to work by the system you're using. Let's use an analogy here. You are a member of a club. This club is very inclusive, but it has a fairly rigid set of protocols that members are expected to follow. For example, when you enter the front door, you are expected to touch a statue next the the door. When a bell rings, you are expected to sing the club song. At precisely 1pm, everyone must kneel in place. A number of other arbitrary actions are required of a new member, and new ones are added every so often. This club is slightly superstitious, so it is believed that *not* performing the required actions is bad luck, and any member who does not perform them to the letter will bring a pox upon the club and all its other members. In fact, the club members have incontrovertable evidence that this is so. The club currently has a membership in the hundreds. They want to be inclusive, so they welcome anybody, and they're glad to get new members. But those who come in are expected to read a slightly tattered printout of a PowerPoint presentation hanging from a string on the inside of the front door. This printout contains all the known actions that a member must perform in response to cues to be a member in good standing. New members can also ask existing members for help, of course, and they can go visit the printout any time. If everyone follows the set of instructions in the powerpoint document to the letter, everything runs swimmingly. But the powerpoint document is missing some pages, (some new cues were added recently) and even if it wasn't, new members would almost always have a hard time getting it *all* right on the first try because there are a lot of cues these days. The bell rings, they kneel. They sing the song at the wrong time. Sometimes they just don't know what to do, so they do nothing. The club also has a wait staff. Currently the wait staff is not expected to enforce any of the rules; they simply keep things running. They are severely underworked at the moment. Currently the club interpersonals are a little broken: when a new member has the wrong response to a cue, the existing club members might try to help that new member, but often they just complain to each other about the offending new member. Some members just claim I've already paid my dues to be a member here, he should too. Other members try to write more little sticky notes and hang them up as cues to new members, but nobody is really responsible for teaching new members the rules. It's sink or swim, and often new members sink. If the the club is the ZCA community, the cues are the worldview that says that the ZCA is by god a way to convert one interface to another and that utility and adapter lookups are no different than each other, the wait staff is the ZCA itself, new members are new developers, and the mistakes they make when not following the cues using methods of the adapted objects that aren't defined by the adapter interface: 1) Put the wait staff in charge of helping new members. This is analogous to making the ZCA throw (or at least warn) about errors that new developers make by using attributes and methods of an object not defined by the interface returned by an adapter or utility lookup. 2) Get rid of most of the cues. This is analogous to unifying adapter lookup and utility lookup by making the *caller* responsible for doing adaptation by calling the result of the lookup himself. Or do nothing. Doing nothing is wrong because at some point *we* become maintainers of code written by folks that didn't get the jokes of the ZCA worldview. So we can either take the joke out or make the joke impossible to miss. I'm not sure why lifetime issues are considered so important here. Of course they sometimes matter. But we use ORMs all the time. We create traversal hierarchies on the fly all the time. What's different in this case? If I want to index an
Re: [Zope-dev] implementing zope.component 4.0
On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli optilude+li...@gmail.com wrote: I think that logically, these are two different concepts that meet two different sets of use cases. Agreed here. This is essential to this discussion. I've been quite surprised that there are so many who argue to unify these ideas. -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
Fred Drake wrote: On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli optilude+li...@gmail.com wrote: I think that logically, these are two different concepts that meet two different sets of use cases. Agreed here. This is essential to this discussion. I've been quite surprised that there are so many who argue to unify these ideas. -Fred Agreed here as well. I think that the different intentions of 1) lookup by interface in registry and 2) adaptation will be easier to understand if the code patterns are different as well. Because I doubt tuple adaptation is that frequent, I am for 5) Call the interface for adaption, and something else for utility lookup, with tuples for multi-adaptation. where the something else is 'Interface.getUtility()'. This way we can - make the interface more prominent when doing lookups (and have some sort of symmetry between lookup and adaptation) - and simultaneously keep the semantic difference between adaptation and lookup. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ 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] z3c.recipe.i18n tests fail
On 2009-12-01 16:36:50 +0100, yuppie y.2...@wcm-solutions.de said:
Christian Zagrodnick wrote:
Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
File /Users/zagy/development/python/lib/python2.6/unittest.py, line
270, in run
self.setUp()
File
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line
2289, in setUp
self._dt_setUp(test)
File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
File
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line
464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'
Should be fixed now. Yuppie
Thanks! And it was such an easy fix! :)
--
Christian Zagrodnick · c...@gocept.com
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · 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
Chris McDonough wrote: Furthermore he'll believe he owns the resulting object, because normal classes are always constructors that create a new object. Except when they don't. Apart from cases like short strings and small integers where Python itself doesn't create objects more than once, you can always implement classes that define __new__ or use metaclasses in such a way that you cannot be sure that (or whether) calling them under given circumstances will create new objects. To be honest, I just don't see why this whole singleton business shouldn't be orthogonal to the concepts of the component architecture. -- 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 )
