Am Mittwoch 25 November 2009 17:54:53 schrieb Chris McDonough:
> Gary Poster wrote:
> > FWIW, I'm saying that utilities and adapters are different. I share
> > your/Martijn's/other people's general thoughts about merging adapters and
> > multiadapters in the interface __call__ syntax.
>
> There m
Chris McDonough wrote:
> Chris McDonough wrote:
>>> If some set of ZCA APIs made it the responsibility of the *caller* to
>>> invoke
>>> the adapter with arguments would go a long way between normalizing the
>>> difference between utilities and adapters (because they would essentially
>>> then
Hanno Schlichting wrote:
> On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver wrote:
>> Hmm, I may be missing something here, but if Foo implements IFoo, then
>> the getAdapter lookup for it will short circuit, leading you into
>> infinite recursion. Except that it doesn't:
>
> [snip example]
>
>> wh
Hey,
Christian Theune wrote:
[snip]
> 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. Howev
On Thu, Nov 26, 2009 at 11:09:35AM -0500, Benji York wrote:
> On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida
> wrote:
> > On Thu, Nov 26, 2009 at 14:34, Benji York 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
Hi there,
Introduction
So now that we've had some discussion and to exit the "bikeshed" phase,
let's see about getting some volunteers to work on this.
The goal here is to make interfaces disappear into the language as much
as possible. This means that I'll ignore backwards compat
Martijn Faassen wrote:
> Are people okay with the proposed semantics?
I am.
> Would people be okay with such an upgrade path? Any better ideas?
I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y)
but maybe that changes after thinking about it some more.
> Most importantl
Martijn Faassen wrote:
> Simple adaptation:
>
>IFoo(adapted)
Is there an implied default of None here or would a ComponentLookupError
be raised?
> Named adaptation:
>
>IFoo(adapted, name="foo")
>
> Adaptation with a default
>
>IFoo(adapted, default=bar)
>
> Multi-adaptation:
>
Summary of messages to the zope-tests list.
Period Thu Nov 26 12:00:00 2009 UTC to Fri Nov 27 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: Thu Nov 26 20:38:26 EST 2009
URL: http://
On Fri, Nov 27, 2009 at 12:32:52PM +0100, Martijn Faassen wrote:
> Hi there,
>
> Introduction
>
>
> So now that we've had some discussion and to exit the "bikeshed" phase,
> let's see about getting some volunteers to work on this.
>
> The goal here is to make interfaces disappear i
> from zope.__future__ import new_adapter_lookup?
Let's leave how special names are created in Python to Python.
We already have __parent__, __annotation__ etc.
What if Python brings a special name which we are using with
a different semantics.
May be we can use special prefix for Zope's own spe
Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> Are people okay with the proposed semantics?
>
> I am.
>
>> Would people be okay with such an upgrade path? Any better ideas?
>
> I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y)
> but maybe that changes after thinking
Chris Withers wrote:
[snip]
> I'd propose just having:
>
> 3.x -> old semantics
> 4.x -> new semantics
That's the Python 3 upgrade scenario, without conversion scripts even. :)
I think this would block people from upgrading to use the new semantics
way too long, as they'd need to ensure all the
Marius Gedminas wrote:
[snip]
> +0.5 --- I can live with it. Backwards incompatibility with IFoo(one,
> default) will be a slight inconvenience. There were proposals I liked
> more (IFoo.adapt(), IFoo.utility()) and proposals I liked less
> (IFoo((one, two, we_like_parentheses, and_screw_people_a
Chris Withers wrote:
> Martijn Faassen wrote:
>> Simple adaptation:
>>
>>IFoo(adapted)
>
> Is there an implied default of None here or would a ComponentLookupError
> be raised?
I'd say a ComponentLookupError. Doesn't it do that now? Anyway, I'd say
if you want a default specify it, otherwis
Baiju M wrote:
>> from zope.__future__ import new_adapter_lookup?
>
> Let's leave how special names are created in Python to Python.
> We already have __parent__, __annotation__ etc.
>
> What if Python brings a special name which we are using with
> a different semantics.
Python's not going to i
On Fri, Nov 27, 2009 at 02:38:55PM +0100, Martijn Faassen wrote:
> I'd ask people to think about this approach without considering
> backwards compatibility issues first. Especially given the goal "making
> component lookup disappear into the language" makes me think just all
> making it calling
Martijn Faassen wrote:
>> +0.5 --- I can live with it. Backwards incompatibility with IFoo(one,
>> default) will be a slight inconvenience. There were proposals I liked
>> more (IFoo.adapt(), IFoo.utility()) and proposals I liked less
>> (IFoo((one, two, we_like_parentheses, and_screw_people_adap
Marius Gedminas wrote:
>> What's the motivation?
>
> The "utilities must be singletons" logic hardcoded in the ZCA.
>
> provideAdapter(factory, adapts=(one, two, three))
> provideAdapter(factory, adapts=(one, two))
> provideAdapter(factory, adapts=(one, ))
>
> The natural progression, to me, is
Marius Gedminas wrote:
[snip]
> The "utilities must be singletons" logic hardcoded in the ZCA.
>
> provideAdapter(factory, adapts=(one, two, three))
> provideAdapter(factory, adapts=(one, two))
> provideAdapter(factory, adapts=(one, ))
>
> The natural progression, to me, is
>
> provideAdapter(fa
Hello Martijn,
I had a feeling that adapter lookup can be alone slowish with lots of
registrations.
We had a large project that was cut in half and the z3c.form UI, which
is rather heavily adaptation based got a boost after that.
Friday, November 27, 2009, 4:25:44 PM, you wrote:
MF> Someone wou
Martijn Faassen wrote:
> Chris McDonough wrote:
>> Chris McDonough wrote:
If some set of ZCA APIs made it the responsibility of the *caller* to
invoke
the adapter with arguments would go a long way between normalizing the
difference between utilities and adapters (because the
Christian Theune wrote:
> 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
Martijn Faassen wrote:
> Hey,
>
> Christian Theune wrote:
> [snip]
>> 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 in
Martijn Faassen wrote:
> Hi there,
>
> Introduction
>
>
> So now that we've had some discussion and to exit the "bikeshed" phase,
> let's see about getting some volunteers to work on this.
>
> The goal here is to make interfaces disappear into the language as much
> as possible.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Are people okay with the proposed semantics?
+1.
> Would people be okay with such an upgrade path? Any better ideas?
I would start issuign DeprecationWarnings (yes, I know I'm their worst
fan, but we can't keep BBB here, so
On Fri, Nov 27, 2009 at 13:11, Marius Gedminas wrote:
> Personally, I prefer Zope's syntax ("decorators" inside the class block)
> to Python's (decorators above the class block), aesthetically.
Yes, but it doesn't work under Python 3. We don't need to remove the
support for Python 2, though, we c
27 matches
Mail list logo
