On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote:
I think I could get fully behind the following proposal that others have made
(Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Change that to Martins IFoo.adapter(...) and I'm behind it to. :-)
Hello,
I've stumbled upon a wrinkly edge case (bug?) in zope.component.
What I was trying to do is register an AbsoluteURL adapter for
lovely.remotetask.processor.ProcessorRequest objects, and since they
don't implement a specific interface, I thought I'd use the class
itself as the required
Martin Aspeli wrote:
Gary Poster wrote:
I think I could get fully behind the following proposal that others have
made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Thinking about it a bit, it strikes me that IFoo.adapt(context) may not
be right. This reads
Wolfgang Schnerring wrote:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
Which will raise
File
Lennart Regebro wrote:
On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote:
I think I could get fully behind the following proposal that others have
made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Change that to Martins IFoo.adapter(...) and
Hey,
Thanks for doing this summary!
Gary Poster wrote:
[snip]
== Utilities available from interfaces ==
As far as I can tell, no one is against this generally, and several
people are for it. Some people are against the syntax that has been
proposed for this that merges utilties and
Gary Poster wrote:
= Why not tuple multi-adaptation in the __call__? =
I'm somewhat surprised that some who have been loudest about not
breaking backwards compatibility are OK with breaking this, given the
two reports from the very small sample we have here of users.
Do you really think
Martin Aspeli wrote:
[snip]
Thinking out loud further, I think I may actually prefer IFoo.instance()
instead of .utility(), but maybe that debate is already passed.
.utility() is OK too.
Haven't you been one of the people who has maintained that changing the
names would do a disservice to
Martijn Faassen wrote:
Martin Aspeli wrote:
[snip]
Thinking out loud further, I think I may actually prefer IFoo.instance()
instead of .utility(), but maybe that debate is already passed.
.utility() is OK too.
Haven't you been one of the people who has maintained that changing the
Summary of messages to the zope-tests list.
Period Wed Dec 2 12:00:00 2009 UTC to Thu Dec 3 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 Dec 2 20:38:22 EST 2009
URL:
Gary Poster wrote:
I think I could get fully behind the following proposal that others
have made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
I was thinking people would get behind the following proposal:
IFoo()
for adaptation and multi adaptation (with tuple
For my 2 cents (not that I think anyone should care):
+1 for IFoo.adapt[er](*args, **kw) and IFoo.utility(*kw)
-1 for tuple adaptation on 1st arg. Besides losing genericity on tuple
adaptation, we risk situations where a class could trigger
multi-adaptation by inheriting from tuple.
+1 for
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway sh...@hathawaymix.org wrote:
To me, myobj.get(x) reads as myobj, please get x and give me the
result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me
the result. That statement makes perfect sense to me.
Agreed. I also like adapt
On Thu, Dec 03, 2009 at 07:44:54AM +0100, Christian Theune wrote:
That reminds me that I had the occasional wish to invoke the ZCA using
some kind of chaining mechanism so that an adapter can ask for the next
less specific adapter that would have been invoked if the former wasn't
there. The
On Thu, Dec 03, 2009 at 08:55:32AM +0100, Wichert Akkerman wrote:
On 2009-12-2 23:06, Marius Gedminas wrote:
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a file name and line
number and inserts a breakpoint at that position.
On Wed, Dec 02, 2009 at 09:14:42PM -0500, Gary Poster wrote:
I think I could get fully behind the following proposal that others have made
(Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
+1 for this.
-1 for IFoo((foo, bar)).
Marius Gedminas
--
http://pov.lt/ --
Martijn Faassen wrote:
I was thinking people would get behind the following proposal:
IFoo()
for adaptation and multi adaptation (with tuple arguments)
and
IFoo.utility()
for utility lookups.
One argument in favor of using plain calls for multi adaptation (using
tuples) is
Jacob Holm wrote:
[snip]
I disagree, breaking backwards compatibility in this particular way
would hurt several projects I am involved in.
Okay, understood.
So I'll go with .adapt() and .utility() and deprecate implicit default
argument.
Regards,
Martijn
On Thu, Dec 03, 2009 at 03:51:06PM +0200, Marius Gedminas wrote:
On Thu, Dec 03, 2009 at 08:55:32AM +0100, Wichert Akkerman wrote:
On 2009-12-2 23:06, Marius Gedminas wrote:
On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote:
Here's another idea: a testrunner option that takes a
On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminas mar...@gedmin.as wrote:
I've had some success with this:
[snip code]
Nice. I'd love to see this wired into the testrunner so people could
specify breakpoints on the command line while running tests.
If no one else gets around to that, I might.
On Dec 3, 2009, at 1:54 AM, Chris McDonough wrote:
My $.02 is here:
http://www.plope.com/Members/chrism/zca_thoughts_summary
I was going to comment on your blog, even though it was separate from the
mailing list, but then I couldn't register an account, so here I am.
I agree with a decent
Gary Poster wrote:
[snip]
I personally think these efforts do not make the potential consensus
on ``adapt`` and ``utility`` methods any less interesting: they would
be a concrete win for my users.
I agree with much of what Gary is saying here.
My ideas:
* I'd like us not to make any lookup
On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote:
Gary Poster wrote:
[snip]
I personally think these efforts do not make the potential consensus
on ``adapt`` and ``utility`` methods any less interesting: they would
be a concrete win for my users.
I agree with much of what Gary is
Gary Poster wrote:
On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote:
Gary Poster wrote: [snip]
I personally think these efforts do not make the potential
consensus on ``adapt`` and ``utility`` methods any less
interesting: they would be a concrete win for my users.
I agree with much of
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
On Dec 3, 2009, at 12:08 PM, Martijn Faassen wrote:
Gary Poster wrote:
On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote:
Gary Poster wrote: [snip]
I personally think these efforts do not make the potential
consensus on ``adapt`` and ``utility`` methods any less
interesting: they would
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'
Am 03.12.2009, 14:18 Uhr, schrieb Benji York be...@zope.com:
Agreed. I also like adapt because it is a verb -- which I prefer
method names to be. For the same reason I'm not real keen on the name
utility... although I can't come up with anything better than
get_utility at the moment.
I've
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
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
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'
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
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
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
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
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
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
38 matches
Mail list logo
