On Thursday 03 December 2009, Marius Gedminas wrote:
IFoo.adapt(...)
IFoo.utility(...)
+1 for this.
-1 for IFoo((foo, bar)).
+1 from me on that too. (I'll join the bandwagon. :-)
Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. Zope Stephan Richter
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. :-)
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
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
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
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 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
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
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(...)
= Why? =
- This is a significant improvement in terms of being memorable, as far as I'm
concerned. It's also briefer, which is related.
- It
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 could get behind this too.
We'd need the current IFoo(context, default) for single adaptation to
continue to work,
On Dec 2, 2009, at 11:09 PM, 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(...)
I could get behind this too.
We'd need the current
Gary Poster wrote:
On Dec 2, 2009, at 11:09 PM, 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(...)
I could get behind this too.
We'd need the
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 IFoo adapt context, which
19 matches
Mail list logo
