Re: [Zope-dev] z3c.schema2xml and z3c.schema2json
Hey, Jan-Wijbrand Kolman wrote: I'm about to work a bit on z3c.schema2json [1]. As has been briefly discussed before (a while ago [2]), z3c. schema2json is so similar to z3c.schema2xml [3] in what it does and how it does it, that I wonder about merging the two packages somehow. One way to do this - maybe - is to use named registrations for the (de)serialization adapters. The name could reflect the serialization mode - for example xml or json. But maybe there're other ideas to achieve this? Or, could it be that merging has no real benefit? I'm still not sure there'd be a real benefit. It depends on how much code would end up being shared. If a lot of code is shared it might make sense to merge them (or factor the code out into a general schema-based serialization and deserialization framework). If it turns out your improvements to z3c.schema2json also make sense in z3c.schema2xml then that's an argument in favor of sharing code between them. 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] improving the utility and adapter lookup APIs
Thomas Lotze wrote: Martijn Faassen wrote: Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Technically, that's obvious. I guess I meant to say How about... then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? True. It's indeed a goal, as I'd like to be able to use this sooner rather than later. If we break backwards compatibility then we'd have to go through all the IFoo() calls everywhere in all our code to see whether a default argument is in use. If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. Sure. But if we want to retain backwards compatibility we'll have to go another way. 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] improving the utility and adapter lookup APIs
Wolfgang Schnerring wrote:
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I quite like the simplicity of this spelling, so I want to be sure
*why* it must be ruled out. (...or does it, really?)
I'm thinking that this...
* Martijn Faassen faas...@startifact.com [2009-11-25 22:21]:
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
is a valid argument, while this...
* Tres Seaver tsea...@palladion.com [2009-11-25 13:34]:
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
is not, as evidenced by...
* Fabio Tranchitella kob...@kobold.it [2009-11-25 20:51]:
IFoo(x, y, default=None, name='something')
or am I missing something here?
I think the problem would exist if we did something like this:
def IFoo(default, name, *args):
pass
but if we did something like this we should be okay, I think:
def IFoo(*args, **kw):
name = kw.get('name', missing)
default = kw.get('default', missing)
adapted = args
So I'm thinking, there is no technical reason that prevents Thomas'
spelling, and I'm wondering, do we really have to preserve backwards
compatibility for this case?
I'm not very fond of the second argument interpreted as default. If it
weren't there I'd be quite interested in the API you're proposing.
But someone needs to think of a feasible upgrade scenario. We could
instrument all calls to IFoo and see whether a default argument is in
use, but what then? I'd be hard to distinguish a default argument from
one we're meant to adapt. I'd also be non-trivial to scan code.
We could perhaps release a special version of
zope.interface/zope.component that *forbids* the second argument to see
what bugs pop up, but that'd still not guarantuee we catch all cases.
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] Releasing zope.browserresource
On 2009-11-26 08:43, Michael Howitz wrote: Am 25.11.2009 um 15:49 schrieb Chris Withers: [...] Yes, PyPI is broken if you're an admin of many packages, feel free to me too on this issue: http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503 It's fixed since yesterday. That's not a fix, it just replaced one problem with another one: it is now impossible to get your full list of packages. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Thomas Lotze wrote: You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? True. It's indeed a goal, as I'd like to be able to use this sooner rather than later. If we break backwards compatibility then we'd have to go through all the IFoo() calls everywhere in all our code to see whether a default argument is in use. Understood. If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. Sure. But if we want to retain backwards compatibility we'll have to go another way. Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. My favourite option under these circumstances would be something like IFoo.query(*args, default=None, ...) though possibly with a method name in a different color of bike shed, where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may be written as IFoo.query(x, y). -- 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: But someone needs to think of a feasible upgrade scenario. We could instrument all calls to IFoo and see whether a default argument is in use, but what then? I'd be hard to distinguish a default argument from one we're meant to adapt. I'd also be non-trivial to scan code. Here is an interface decorator I intend to try out soon. It adds convenient component lookup methods to a particular interface without requiring any changes to zope.interface. --- (snip) --- from zope.interface.interfaces import IInterface from zope.component import getAdapter from zope.component import getMultiAdapter from zope.component import getUtility from zope.component import queryAdapter from zope.component import queryMultiAdapter from zope.component import queryUtility def componentlookup(iface): Decorator: adds zope.component lookup methods to an interface. Adds utility([default], [name]) and adapt(*args, [default], [name]). assert IInterface.providedBy(iface) def utility(**kw): if 'default' in kw: return queryUtility(iface, **kw) else: return getUtility(iface, **kw) iface.utility = utility def adapt(*args, **kw): if len(args) == 1: # simple adapter lookup arg = args[0] if not 'name' in kw and iface.providedBy(arg): # The object passed in already provides this interface, # and no adapter name was provided, so return the object # unchanged. return arg if 'default' in kw: return queryAdapter(arg, iface, **kw) else: return getAdapter(arg, iface, **kw) # multi-adapter lookup if 'default' in kw: return queryMultiAdapter(args, iface, **kw) else: return getMultiAdapter(args, iface, **kw) iface.adapt = adapt return iface --- (snip) --- Example usage: @componentlookup class IFoo(Interface): pass class Foo(object): implements(IFoo) IFoo.adapt(Foo()) IFoo.adapt(Foo(), HTTPRequest(), name='edit') IFoo.adapt(Foo(), name='x') IFoo.adapt(Foo(), default=None) IFoo.utility(default=None) I think class decorators were added in Python 2.6, but in earlier Pythons you can do this instead: class IFoo(Interface): pass componentlookup(IFoo) 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] Zope3 server with SIGSEGV - what to do?
Am Mittwoch 25 November 2009 13:07:58 schrieb Benji York: On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer du...@qwer.tk wrote: Ah, thanks that could be. My current version is zope.security-3.4.1 (as from KGS-3.4.0). The real bad thing about this is that it seems I'm stuck with that release as trying to upgrade to zope.security-3.7.1 fails due to dependencies. So I'd have to upgrade all packages (btw., there seems not to be any current KGS?). Yep. The introduction of so many non-backward-compatible changes in the last few years has also caused me great pain. Any ideas how to solve this? If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release. Thanks a lot for help, that would really great. The question is, how do I find out (with my limited knowledge of zope.security) if the bug exists in 3.4.1? I saw in your link you sent me that a core-dump can be made somehow, how can this be done? Because via that core-dump I expect we can pinpoint the reason and confirm the bug for zope.security-3.4.1? 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] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Wed Nov 25 12:00:00 2009 UTC to Thu Nov 26 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: Wed Nov 25 20:38:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013083.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Nov 25 20:40:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013084.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Nov 25 20:42:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013085.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Nov 25 20:44:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013086.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Nov 25 20:46:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013087.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Nov 25 20:48:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013088.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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) While this would be a multi-adapter lookup: IFoo(my_tuple) -- Benji York ___ 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] Releasing zope.browserresource
On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman wich...@wiggy.net wrote: That's not a fix, it just replaced one problem with another one: it is now impossible to get your full list of packages. Indeed. Once SourceForge is allowing logins again I suggest we discuss this there. I'll be suggesting that the recent fix be reverted and they instead use the CSS I posted earlier. -- Benji York ___ 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 Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. Cheers, Leo ___ 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] Zope3 server with SIGSEGV - what to do?
On Thu, Nov 26, 2009 at 6:52 AM, Hermann Himmelbauer du...@qwer.tk wrote: If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release. Thanks a lot for help, that would really great. The question is, how do I find out (with my limited knowledge of zope.security) if the bug exists in 3.4.1? From looking at the code, it seems the bug does exist in 3.4.1 (and 3.4.2). I merged the fix to the 3.4 branch and released 3.4.3. I saw in your link you sent me that a core-dump can be made somehow, how can this be done? Because via that core-dump I expect we can pinpoint the reason and confirm the bug for zope.security-3.4.1? As a first step, I suggest putting 3.4.3 in production and seeing if the segfaults stop. -- Benji York ___ 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.schema2xml and z3c.schema2json
2009/11/26 Martijn Faassen faas...@startifact.com: Hey, Jan-Wijbrand Kolman wrote: I'm about to work a bit on z3c.schema2json [1]. As has been briefly discussed before (a while ago [2]), z3c. schema2json is so similar to z3c.schema2xml [3] in what it does and how it does it, that I wonder about merging the two packages somehow. One way to do this - maybe - is to use named registrations for the (de)serialization adapters. The name could reflect the serialization mode - for example xml or json. But maybe there're other ideas to achieve this? Or, could it be that merging has no real benefit? I'm still not sure there'd be a real benefit. It depends on how much code would end up being shared. If a lot of code is shared it might make sense to merge them (or factor the code out into a general schema-based serialization and deserialization framework). If it turns out your improvements to z3c.schema2json also make sense in z3c.schema2xml then that's an argument in favor of sharing code between them. I can't see much core code being shared to be honest. However, the benefits of merging would be more apparent to clients of these modules who want to be able to use z3c.schema2json and z3c.schema2xml together to support both serialization formats. I can see two use cases from the perspective of client code: * I want to have my objects serialized and deserialized but don't want to know what format is used, just use an agnostic interface (z3c.autoinclude wires the correct implementation from the list of dependencies). * I want to present a list of possible serialization formats and have the user select the appropriate one. Thanks, Paul ___ 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 Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). Nope, it hadn't occurred to me. Some other argument name could be used instead. While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. I'd rather have the common case (of adapting a non-tuple) be the simpler form and the exception (adapting a tuple) require more verbiage. -- Benji York ___ 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
Shane Hathaway wrote: [I talk about backwards compatibility issues with some proposed API changes, but this modification doesn't have this issue] Here is an interface decorator I intend to try out soon. It adds convenient component lookup methods to a particular interface without requiring any changes to zope.interface. Cool! It'd be cool if this could be released as a package. I would still propose folding this into zope.component (somehow) and making interfaces do this by default. This is because the decorator as far as I understand requires one to be in control of the 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] improving the utility and adapter lookup APIs
Thomas Lotze wrote: [snip] Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. That was my original proposal, right? (I only propose adding a 'name' argument to the IFoo() lookup if it isn't there already, otherwise it's all new methods). My favourite option under these circumstances would be something like IFoo.query(*args, default=None, ...) though possibly with a method name in a different color of bike shed, where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may be written as IFoo.query(x, y). It could indeed be done as a single method. See Shane's post for a possible implementation. 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Thomas Lotze wrote: [snip] Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. That was my original proposal, right? (I only propose adding a 'name' argument to the IFoo() lookup if it isn't there already, otherwise it's all new methods). I specifically wanted to suggest not adding that name argument but leaving the existing call untouched. I think once we add a new method, we shouldn't at the same time improve the existing one as that would IMO suggest rather forcefully that there's more than one way to do the same thing; just leaving it in there for compatibility is bad enough from the point of view of a clean API. -- 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] make zope.component.registry.Components inherit from dict?
Hi, On 11/25/2009 02:35 AM, Chris McDonough wrote: Chris McDonough wrote: I think it makes sense. If we can relax the utility name must be a string restriction it would be the best solution I think. I'll see what I can do. I've decided to keep the components subclass which inherits from dict. Just for clarification as I'm confused now from reading the back-and-forth-maybe-lets-not-play-together stuff all at once: that means you're going down an incompatible route rolling your own convenience mechanism? 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] improving the utility and adapter lookup APIs
On 11/25/2009 08:51 PM, Fabio Tranchitella wrote: * 2009-11-25 19:35, Tres Seaver wrote: IFoo() IFoo(x) IFoo(x, y) You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. I'm probably saying something very stupid... What's wrong with the it? Can't we define something like: def __call__(self, *args, **kw): to get a multi adapter in this way? IFoo(x, y, default=None, name='something') That's what I thought of as well. The __call__ signature isn't as expressive as before with that but I'm relatively sure it's a valid implementation of Thomas' suggestions. Tres? -- 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] improving the utility and adapter lookup APIs
On 11/26/2009 10:48 AM, Martijn Faassen wrote: Thomas Lotze wrote: Martijn Faassen wrote: Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I like the interface being called to be the motion of doing anything with the CA that doesn't expose the CA mechanics to application developers as much. The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Technically, that's obvious. I guess I meant to say How about... then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? True. It's indeed a goal, as I'd like to be able to use this sooner rather than later. If we break backwards compatibility then we'd have to go through all the IFoo() calls everywhere in all our code to see whether a default argument is in use. Another option would be to provide a backwards-compatibility mode of our code which can be switched on and off. Your notion of bringing the component lookup mechanics closer to being a language feature is very intriguing and I like it a lot. However, if we do so, I'd like us to not having to resort to second-best spelling/implementation due to backwards compatbility. I'd like to work pretty hard on doing the implementation we want because it's a good implementation and then make backwards compatibility work. (I know, I'm a dreamer ...) 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] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
On 11/25/2009 08:51 PM, Fabio Tranchitella wrote:
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
I'm probably saying something very stupid... What's wrong with the it?
Can't we define something like:
def __call__(self, *args, **kw):
to get a multi adapter in this way?
IFoo(x, y, default=None, name='something')
That's what I thought of as well. The __call__ signature isn't as
expressive as before with that but I'm relatively sure it's a valid
implementation of Thomas' suggestions.
Tres?
Two issues:
- - The proposed spelling weakens documentation / enforceabiliy of the
contract ('**kw' doesn't tell you what the allowed keys are, and in
fact implies that you can pass arbitrary keys).
- - It's backward-incompatible: there are cases in the wild using
'default' as a positional parameter.
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
iEYEARECAAYFAksPgY0ACgkQ+gerLs4ltQ5X9QCdF7X3safMgFuofqjQuOiFfUS+
eEgAn0PbN3cNNdoYiuZh5h86AyXwnP7m
=mdBp
-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 )
