the ZCA API decision
Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] Hopefully we can move forward towards implementation. Thomas Lotze, are you happy enough with this to still help with the implementation? Thanks everybody for your participation in the discussion! Regards, Martijn
Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this:
An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments.
A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments.
On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz).
[steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)]
A general +0 from me, because it seems to be 99% bw compat and does no harm. - C
Martijn Faassen wrote:
Thomas Lotze, are you happy enough with this to still help with the implementation?
I am indeed. This isn't the ideal solution I had hoped for, but it is a big step in a good direction from my point of view and I don't see any part of it that might take us away from the ideal solution which I still hope we can implement at some point in the future. How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first? -- Thomas
On Dec 3, 2009, at 3:33 PM, Thomas Lotze wrote:
Martijn Faassen wrote:
Thomas Lotze, are you happy enough with this to still help with the implementation?
I am indeed. This isn't the ideal solution I had hoped for, but it is a big step in a good direction from my point of view and I don't see any part of it that might take us away from the ideal solution which I still hope we can implement at some point in the future.
How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first?
I don't know if too much experimentation is needed for this in particular. I would think we would want to follow the pattern of the adapter_hooks in zope.interface.interface, including the C optimizations. I would be comfortable with you leading the effort, in a shared branch, if that works for you. You could specify what parts you wanted help on. Or would you prefer someone else to take charge? Gary
Gary Poster wrote:
I don't know if too much experimentation is needed for this in particular.
I would think we would want to follow the pattern of the adapter_hooks in zope.interface.interface, including the C optimizations.
I would be comfortable with you leading the effort, in a shared branch, if that works for you. You could specify what parts you wanted help on.
Or would you prefer someone else to take charge?
I'd be happy to lead this effort, if you like to put it like that. I wouldn't want to take it out of Martijn's hands, though, unless he's happy with it as well, given that he's the one who started the discussion. As for any technical questions, it's too late in the night over here now for me to say anything serious, so I'll reply to that tomorrow. -- Thomas
Thomas Lotze wrote: [snip]
I'd be happy to lead this effort, if you like to put it like that. I wouldn't want to take it out of Martijn's hands, though, unless he's happy with it as well, given that he's the one who started the discussion.
By all means take the lead on the implementation. :) Regards, Martijn
Gary Poster wrote:
I would think we would want to follow the pattern of the adapter_hooks in zope.interface.interface, including the C optimizations.
Speaking of adapter hooks: If I'm not completely mistaken, adapter hooks know about exactly one object to be adapted. To follow the pattern of adapter hooks in the implementation of our new lookup methods, we need hooks that handle zero, one or more objects instead. We could work with a second set of hooks in order to keep the existing ones untouched, but that would require every user of the hooks feature to implement both kinds of hooks. We could also change the signature of adapter hooks, which would be backwards-incompatible, either with tuple adaptation or with named adapters (since the name is the first keyword argument for adapter hooks). So I'd like to hear opinions: Would a backwards-incompatible change to adapter hooks be acceptable, considering that this wouldn't be visible to users of the component architecture but only to implementors of component frameworks like zope.component? -- Thomas
Thomas Lotze wrote: [snip]
How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first?
I think you're the main volunteer we have to work on this, so I suggest you try your stuff on a branch. Once it's ready for review just post about it here and prod some people. :) I'd like to see about gathering/writing some documentation and also integrating it into zope.component, but that can be a separate activity. Other work like the stuff Gary and Chris have been talking about can proceed independently. Looking forward to your work! Regards, Martijn P.S. I most likely won't be around next week to review anything, just FYI.
Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this:
An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments.
A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments.
On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz).
I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed.
[steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)]
Hopefully we can move forward towards implementation.
Thomas Lotze, are you happy enough with this to still help with the implementation?
Thanks everybody for your participation in the discussion!
Regards,
Martijn
-- Godefroid Chapelle (aka __gotcha) http://bubblenet.be
Godefroid Chapelle wrote:
I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed.
AFAICT, the decision to reject or postpone that has been postponed. :-) Shane
On Thu, Dec 03, 2009 at 03:11:07PM -0700, Shane Hathaway wrote:
Godefroid Chapelle wrote:
I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed.
AFAICT, the decision to reject or postpone that has been postponed. :-)
While taking steps now to soften the backwards compatibility issues for that future decision. -- Brian Sutherland
Brian Sutherland wrote:
On Thu, Dec 03, 2009 at 03:11:07PM -0700, Shane Hathaway wrote:
Godefroid Chapelle wrote:
I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed. AFAICT, the decision to reject or postpone that has been postponed. :-)
While taking steps now to soften the backwards compatibility issues for that future decision.
Yes, but luckily that step can be motivated quite well from a code readability perspective too. :) Regards, Martijn
Godefroid Chapelle wrote: [snip]
I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed.
Multi adaptation with IFoo(foo, bar) is off the agenda. Whether that means a permanent rejection or a postponement depends on the future. Regards, Martijn
Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision.
I'm a little worried that neither Stephan Richter, nor Jim Fulton have had much weight in on this. They seem like important stakeholders. :)
Hopefully everybody is at least reasonably happy with this:
An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments.
+1
A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments.
+1
On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz).
+1
[steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)]
I'd give them a week or so at least... this is deep stuff. ;)
Hopefully we can move forward towards implementation.
Thomas Lotze, are you happy enough with this to still help with the implementation?
Thanks everybody for your participation in the discussion!
Can we all get back to our lives now? :-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Can we all get back to our lives now? :-)
FWIW, I try to participate in discussions like these by reading and writing only short emails. I find that I don't miss much that way. Life is more enjoyable without essay-mails. Shane
Shane Hathaway wrote:
Martin Aspeli wrote:
Can we all get back to our lives now? :-)
FWIW, I try to participate in discussions like these by reading and writing only short emails. I find that I don't miss much that way. Life is more enjoyable without essay-mails.
You don't know me very well, apparently... ;-) Martin 'verbose' Aspeli -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision.
I'm a little worried that neither Stephan Richter, nor Jim Fulton have had much weight in on this. They seem like important stakeholders. :)
Stephan has chipped in on this discussion several time and my impression is that he's okay with this. As for Jim, I know in an earlier discussion last year or so that he was all right with some work being done on this.
I'd give them a week or so at least... this is deep stuff. ;)
I'd say proceed with the implementation on a branch right now. I would imagine any objections could still be handled before merging the work. Regards, Martijn
On Fri, Dec 4, 2009 at 8:27 AM, Martijn Faassen <faassen@startifact.com> wrote:
Martin Aspeli wrote:
Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision.
I'm a little worried that neither Stephan Richter, nor Jim Fulton have had much weight in on this. They seem like important stakeholders. :)
Stephan has chipped in on this discussion several time and my impression is that he's okay with this.
As for Jim, I know in an earlier discussion last year or so that he was all right with some work being done on this.
I'm fine with the final outcome (IFoo.adapt(...), IFoo.utility(...), and moving toward requiring default as kw arg in IFoo()). Jim -- Jim Fulton
I'm +1 on this decision, and would also like to announce that I have cleaned up my Python3 compatible branch of zope.interface. Even though the decision now is to only add new stuff and not break any backwards compatibility I think adding the Python 3 support into 4.0 would be a good time to add this anyway, so we get all API changes at once, even if they are fully backwards compatible. http://svn.zope.org/zope.interface/branches/regebro-python3/ People who are doing strange things with ZCA are encouraged to test it. I have tested Plone 3.3.1 with it, so I seem to have not broken anything. :) I can make an sdist if anyone wants. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
I'm +1 on this decision, and would also like to announce that I have cleaned up my Python3 compatible branch of zope.interface. Even though the decision now is to only add new stuff and not break any backwards compatibility I think adding the Python 3 support into 4.0 would be a good time to add this anyway, so we get all API changes at once, even if they are fully backwards compatible.
Do we still want to call the new release 4.0 if no backwards-incompatible change is going to be made? -- Thomas
Thomas Lotze wrote:
Lennart Regebro wrote:
I'm +1 on this decision, and would also like to announce that I have cleaned up my Python3 compatible branch of zope.interface. Even though the decision now is to only add new stuff and not break any backwards compatibility I think adding the Python 3 support into 4.0 would be a good time to add this anyway, so we get all API changes at once, even if they are fully backwards compatible.
Do we still want to call the new release 4.0 if no backwards-incompatible change is going to be made?
I think it's okay to call it 4.0. While it's not incompatible, it will have major practical differences in usage. We should also have better documentation at that point. :) We'll also need to see what Gary's underlying refactoring work comes up with. It's quite possible it won't land in time or it'll be done outside of zope.component, but who knows. We can delay the final decision nearer to the actual release of these features. Regards, Martijn
On Thu, Dec 03, 2009 at 06:41:03PM +0100, Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this:
An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments.
A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments.
On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz).
FWIW, I'm +1 as well. -- Brian Sutherland
Hi, On 12/03/2009 06:41 PM, Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this:
An "adapt()" method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments.
A "utility()" method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments.
On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz).
[steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)]
I'm assenting loudly as I'm happy to see progress on this issue. Christian -- Christian Theune · ct@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
participants (11)
-
Brian Sutherland -
Chris McDonough -
Christian Theune -
Gary Poster -
Godefroid Chapelle -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Shane Hathaway -
Thomas Lotze