Hi Jim,
Do I remember well that you did the last optimization round around
adapters?
If yes, did you have some tests for that, they could be handy now.
Saturday, November 28, 2009, 12:14:42 PM, you wrote:
MF> Adam GROSZER wrote:
>> I had a feeling that adapter lookup can be alone slowish with lo
Chris McDonough wrote:
> Thomas Lotze wrote:
>> Martijn Faassen wrote:
>>
>>> * a utility never has a connection. That's because it already got
>>> instantiated long before the lookup takes place.
>> Isn't it the other way around: A utility never has a connection to any
>> adapted object, and that'
On Wednesday 02 December 2009, Lennart Regebro wrote:
> When there is such a clear and distinct conceptual difference between
> adapters and utilities, why would we try to murk that distinction by
> pretending that non adapters are a special case of adapters, when it's
> obvious that that's exactly
Unifying adapters and utilities gets us nowhere.
If we remove the distinction between an adapter and a utility we are
simply left with the concept of "component". Then we have components,
nothing else. Components are objects registered base on what interface
they implement, and can be looked up ba
Gary Poster wrote:
> Without this distinction, AFAICT either you want to conflate the ideas, or
> you have a concept of the differences between the two that is more
> esoteric than I think is useful. I get the impression that it is on the
> second point of those that we disagree.
Right, I unders
On Dec 2, 2009, at 8:58 AM, Fred Drake wrote:
> On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster wrote:
>> You are arguing for the unification of utilities and adapters?
>
> No. I'm arguing not to conflate utilities with the singleton pattern
> or adaptation with ownership of the resulting adaptati
Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> * a utility never has a connection. That's because it already got
>> instantiated long before the lookup takes place.
>
> Isn't it the other way around: A utility never has a connection to any
> adapted object, and that's *why we can* instantiate
Martijn Faassen wrote:
> * a utility never has a connection. That's because it already got
> instantiated long before the lookup takes place.
Isn't it the other way around: A utility never has a connection to any
adapted object, and that's *why we can* instantiate it long before the
lookup takes
On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster wrote:
> You are arguing for the unification of utilities and adapters?
No. I'm arguing not to conflate utilities with the singleton pattern
or adaptation with ownership of the resulting adaptation.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the s
Gary Poster wrote:
>
> On Dec 2, 2009, at 8:33 AM, Fred Drake wrote:
>
>> On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote:
>>> To be honest, I just don't see why this whole singleton business
>>> shouldn't be orthogonal to the concepts of the component architecture.
>>
>> Well said. If an
On Dec 2, 2009, at 8:33 AM, Fred Drake wrote:
> On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote:
>> To be honest, I just don't see why this whole singleton business shouldn't
>> be orthogonal to the concepts of the component architecture.
>
> Well said. If an application cares about singlet
On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote:
> To be honest, I just don't see why this whole singleton business shouldn't
> be orthogonal to the concepts of the component architecture.
Well said. If an application cares about singleton creation or
ownership of factory-returned objects, it
Chris McDonough wrote:
> Furthermore he'll believe he "owns" the resulting object, because normal
> classes are always constructors that create a new object.
Except when they don't. Apart from cases like short strings and small
integers where Python itself doesn't create objects more than once, y
Fred Drake wrote:
> On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli
> wrote:
>> I think
>> that logically, these are two different concepts that meet two different
>> sets of use cases.
>
> Agreed here. This is essential to this discussion.
>
> I've been quite surprised that there are so many w
On Tue, Dec 1, 2009 at 11:34 AM, Martin Aspeli wrote:
> I think
> that logically, these are two different concepts that meet two different
> sets of use cases.
Agreed here. This is essential to this discussion.
I've been quite surprised that there are so many who argue to unify these ideas.
Joachim König wrote:
> Martin Aspeli wrote:
>> Clearly, it could. But that's not the way we went. Changing it now would
>> be really damaging, and I'm not sure what would be gained.
>>
>> I can imagine use cases where getting a new instance each time would be
>> useful.
> But that is under the fu
Martin Aspeli wrote:
> Clearly, it could. But that's not the way we went. Changing it now would
> be really damaging, and I'm not sure what would be gained.
>
> I can imagine use cases where getting a new instance each time would be
> useful.
But that is under the full controll of the __call__ of
Martijn Faassen wrote:
> Joachim König wrote:
> [snip]
>> To me the fact that an object "is" a singleton or a factory is
>> orthogonal to the registry stuff.
>>
>> Why can't utilities be factories too that simply return themselves when
>> being called? Then being
>> a singleton or not would be in
Joachim König wrote:
[snip]
> To me the fact that an object "is" a singleton or a factory is
> orthogonal to the registry stuff.
>
> Why can't utilities be factories too that simply return themselves when
> being called? Then being
> a singleton or not would be in the responsibility of the regis
On Tue, Dec 1, 2009 at 3:38 PM, Martin Aspeli wrote:
> I'm certainly -1 on using the term in the ZCA. I think changing our
> nomenclature would be terrible for the same reasons I think changing (as
> opposed to extending/improving) our API would be terrible. Utilities are
> in one way a more speci
Martin Aspeli wrote:
> For the record, I normally use the singleton analogy to explain unnamed
> global utilities. Perhaps that's bad, though I find it works pretty
> well. It'd probably be more accurate to use the terms you did, an
> "extension of the singleton principle", but as you say, it ju
Martijn Faassen wrote:
> I don't like the word singleton very much either. Singleton in the
> Design Patterns book has a very particular implementation that is
> criticized by a lot of developers and in particular that particular
> pattern is very uncommon in the Python world (people just use g
Chris McDonough wrote:
> Tres Seaver wrote:
[snip]
>> The root of the disagreement here is that you seem to want the *caller*
>> to care about something which is important only to the person who
>> *registers* the thing being looked up. From the caller's perspective,
>> the call site needs an obje
Gary Poster wrote:
> Then to the multiadapter concern I raised, all my real-world examples
> of adapters are to adapt one object so it can be used in a certain
> way (to integrate with another kind of object). Power adapters, for
> instance, adapt a plug (required interface) so it can plugged in t
Shane Hathaway wrote:
[a lookup method instead of calling the interface]
> What do you think?
Two objections to a method "lookup":
* I do like the notion of "casting" an object with an interface. We can
at least interpret single adaptation that way.
* doing a call better makes this lookup mecha
Am Montag 30 November 2009 16:57:11 schrieb Gary Poster:
> 1) The term "adapter" is a barrier to understandability, in my interviews.
> This is particularly the case when people are introduced to the idea of
> "multiadapter" and "supscription adapter". In what ways are these anything
> like a typ
Gary Poster wrote:
> On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote:
>
> Then to the multiadapter concern I raised, all my real-world examples of
> adapters are to adapt one object so it can be used in a certain way (to
> integrate with another kind of object). Power adapters, for instance, a
Martijn Faassen wrote:
> Stephan Richter wrote:
>> On Friday 27 November 2009, Martijn Faassen wrote:
>>> Are people okay with the proposed semantics?
>>>
>>> Would people be okay with such an upgrade path? Any better ideas?
>> Looks good.
>>
>> Note: We had Thanks Giving over the weekend, so pleas
Martijn Faassen wrote:
> The most elegant backwards compatible solution would be multi adaptation
> using a tuple. I think 'name' can probably also be added to the adapter
> hook without breaking stuff. People adapting tuples will need an
> explicit way to do so. It's still backwards incompatib
Gary Poster wrote:
> Then to the multiadapter concern I raised, all my real-world examples
> of adapters are to adapt one object so it can be used in a certain
> way (to integrate with another kind of object). Power adapters, for
> instance, adapt a plug (required interface) so it can plugged in t
On Mon, Nov 30, 2009 at 5:14 PM, Lennart Regebro wrote:
> True. For me utilities are tools. Like CMFs portal_whatever. But in
> Zope3 even small stupid singleton objects are utilities in some cases,
> and that is confusing for a beginner.
I wonder how many typical Python programmers know the term
On Mon, Nov 30, 2009 at 22:40, Gary Poster wrote:
> Then to the multiadapter concern I raised, all my real-world examples of
> adapters are to adapt one object so it can be used in a certain way (to
> integrate with another kind of object). Power adapters, for instance, adapt
> a plug (require
On Nov 30, 2009, at 4:40 PM, Gary Poster wrote:
> Put yet another way, how are 99+% of our "utility" usages not singletons?
Therein lies the problem.
Singletons are singletons in 100% of cases.
Since utilities are not singletons in 100% of cases they are not singletons by
definition.
> If that's
On Nov 30, 2009, at 4:13 PM, Zvezdan Petkovic wrote:
>
> On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote:
>
>> On Nov 30, 2009, at 2:24 PM, Gary Poster wrote:
>>> 3) I also think that "utility" is a bad name. Is "singleton" two letters
>>> too long?
>>
>> Yes and not because "singleton"
On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote:
> Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster :
>
>> 1) I very much like the idea of some helpers hanging around. However,
>> my current belief is that the factory "methods" ought to be callable
>> objects that allow introspection of the u
On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote:
> On Nov 30, 2009, at 2:24 PM, Gary Poster wrote:
>> 3) I also think that "utility" is a bad name. Is "singleton" two letters
>> too long?
>
> Yes and not because "singleton" is longer.
> It just a bad name.
> :-)
To clarify because of
On Nov 30, 2009, at 2:24 PM, Gary Poster wrote:
> 3) I also think that "utility" is a bad name. Is "singleton" two letters too
> long?
Yes and not because "singleton" is longer.
It just a bad name.
:-)
___
Zope-Dev maillist - Zope-Dev@zope.org
https
Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster :
> 1) I very much like the idea of some helpers hanging around. However,
> my current belief is that the factory "methods" ought to be callable
> objects that allow introspection of the underlying registry. That's
> where the "lookup" style be
Am 30.11.2009, 19:51 Uhr, schrieb Chris McDonough :
> + 1 with the following caveat:
> I think that method name should probably be "adapt"; "lookup" should
> maybe be
> a separate method reserved for passing bare interfaces rather than
> objects
> which implement interfaces, e.g:
> >>> IFoo
On Nov 30, 2009, at 11:47 AM, Martijn Faassen wrote:
> Hey,
>
> Gary Poster wrote:
>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
...snipping here and elsewhere without further warning...
>>> Utility lookup:
>>>
>>> IFoo()
>>>
>>> Named utility lookup:
>>>
>>> IFoo(name="foo")
>>>
On Nov 30, 2009, at 1:51 PM, Chris McDonough wrote:
> Shane Hathaway wrote:
...a good general argument, that Chris seemed to agree with and expand upon,
and that has some merit to me.
>
>> What do you think?
>
> + 1 with the following caveat:
>
> I think that method name should probably be
Shane Hathaway wrote:
> Martijn Faassen wrote:
>> Given some feedback about backwards compatibility, I'm leaning to the
>> following adjusted scenario:
>>
>> * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation.
>> It's not as pretty as IFoo(a, b), but it's pretty tolerable and
Lennart Regebro wrote:
> On Mon, Nov 30, 2009 at 19:16, Shane Hathaway wrote:
>> If adding lookup() is a good idea
>
> Possibly, but it sound like you are looking up (a), when in fact you
> are adapting it. :) Maye IFoo.adapt(a) ?
+1, IFoo.adapt() is better, along with IFoo.utility().
Shane
___
Am Montag 30 November 2009 16:57:11 schrieb Gary Poster:
> As above, I disagree.
>
> As a matter of mechanics, when you register something we call an adapter,
> it is a callable that takes one or more arguments. If we were going to
> follow the pattern that Marius laid out to establish what ha
On Mon, Nov 30, 2009 at 19:16, Shane Hathaway wrote:
> If adding lookup() is a good idea
Possibly, but it sound like you are looking up (a), when in fact you
are adapting it. :) Maye IFoo.adapt(a) ?
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
Martijn Faassen wrote:
> Given some feedback about backwards compatibility, I'm leaning to the
> following adjusted scenario:
>
> * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation.
> It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is*
> actually symmetr
On Mon, Nov 30, 2009 at 08:40, Wolfgang Schnerring wrote:
> Thus, we should not start requiring zope.component 4.0 everywhere
> immediately (because it's new, great and shiny ;), but rather use
> 3.9+future when we want to use the new semantics, and only after I don't
> know, 6 months maybe, start
On Nov 30, 2009, at 11:51 AM, Chris McDonough wrote:
> Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Gary Poster wrote:
>>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
>>
Utility lookups versus adapter lookups
Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 5:09 PM, Martijn Faassen
> wrote:
>> Leonardo Rochael Almeida wrote:
>>> * Use a different package name!
>> We don't have that option, as we're talking about changing the behavior
>> of calling IFoo.
>
> It's very well possible. You create a ne
Tres Seaver wrote:
[snip]
> Do we really have a significant codebase which both needs to adapt
> tuples *and* uses the interface-calling sugar?
I hope not. That's why I walk all over it breaking backwards
compatibility in this plan.
We'd need to live with IFoo((a, b)) for a few years as opposed
Stephan Richter wrote:
> On Monday 30 November 2009, Martijn Faassen wrote:
>> * we can then allow tuple adaptation again. :)
>
> Tuple adaption was also really important to the Twisted guys. We should
> consult them to see whether they are still using zope.component and whether
> they are still
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Gary Poster wrote:
>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
>
>>> Utility lookups versus adapter lookups
>>> --
>>>
>>> There was some discussion on whether utility lookups a
Hey,
Gary Poster wrote:
> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
[snip]
>> So now that we've had some discussion and to exit the "bikeshed"
>> phase,
>
> Wow. That's abrupt, for something at the root of the entire stack.
I realize now that exiting the bikeshed phase was premature.
On Mon, Nov 30, 2009 at 5:09 PM, Martijn Faassen wrote:
> Leonardo Rochael Almeida wrote:
>> * Use a different package name!
>
> We don't have that option, as we're talking about changing the behavior
> of calling IFoo.
It's very well possible. You create a new distribution called for
example "I
On Monday 30 November 2009, Martijn Faassen wrote:
> * we can then allow tuple adaptation again. :)
Tuple adaption was also really important to the Twisted guys. We should
consult them to see whether they are still using zope.component and whether
they are still adapting tuples.
Regards,
Stepha
Hey,
Wichert Akkerman wrote:
[snip]
> We could also say that we will clean up the API when we move to Python
> 3. That is a natural breaking point anyway, so it will not any extra
> pain for users of the ZCA.
In my opinion, that would be the absolute worst possible moment.
Motivation:
http://
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Stephan Richter wrote:
>> On Friday 27 November 2009, Martijn Faassen wrote:
>>> Are people okay with the proposed semantics?
>>>
>>> Would people be okay with such an upgrade path? Any better ideas?
>> Looks good.
>>
>> Note:
Hey,
[Python 3 discussions]
I think discussions about Python 3 and changing the API then should be
tabled in this thread. We're talking about a timeline where the first
steps will take place in the next few months. Realistic small steps,
please. (just like we'll need realistic small steps towa
Stephan Richter wrote:
> On Friday 27 November 2009, Martijn Faassen wrote:
>> Are people okay with the proposed semantics?
>>
>> Would people be okay with such an upgrade path? Any better ideas?
>
> Looks good.
>
> Note: We had Thanks Giving over the weekend, so please allow more US people,
> l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Gary Poster wrote:
>> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
>
>>> Utility lookups versus adapter lookups
>>> --
>>>
>>> There was some discussion on whether utility lookups are rea
Lennart Regebro wrote:
> On Sat, Nov 28, 2009 at 16:39, Charlie Clark
>> The
>> most common example I know of the syntax is with INameChooser() which
>> brings us back to the differences (real or imaginary) between utilities
>> and adapters.
>
> I agree that calling an interface like that is a st
Leonardo Rochael Almeida wrote:
> I find it rather odd that we're wasting so much time worrying about
> backward incompatibility when we have a perfect mechanism to introduce
> backward incompatible changes in a way that allows both flavours to be
> used by packages in the same application (on a mo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
> On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
>> Utility lookups versus adapter lookups
>> --
>>
>> There was some discussion on whether utility lookups are really
>> something fundamenta
Martin Aspeli wrote:
> Martijn Faassen wrote:
[snip]
>> That's why I think it's important to have a:
>>
>> * a zope.component 3.x that supports both patterns
>>
>> * a per-module way to indicate whether the new API should be used.
>
> Sorry, I just don't buy it. The *moment* someone requires >= 4.
On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote:
> Hi there,
>
> Introduction
>
>
> So now that we've had some discussion and to exit the "bikeshed" phase,
Wow. That's abrupt, for something at the root of the entire stack.
I don't think long emails are very effective, but I'
Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wrote:
>> We could also say that we will clean up the API when we move to Python
>> 3. That is a natural breaking point anyway, so it will not any extra
>> pain for users of the ZCA.
>
> Except that is precisely what the
On Friday 27 November 2009, Martijn Faassen wrote:
> Are people okay with the proposed semantics?
>
> Would people be okay with such an upgrade path? Any better ideas?
Looks good.
Note: We had Thanks Giving over the weekend, so please allow more US people,
like Jim, to comment before finalizing
On 11/30/09 14:45 , Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wrote:
>> We could also say that we will clean up the API when we move to Python
>> 3. That is a natural breaking point anyway, so it will not any extra
>> pain for users of the ZCA.
>
> Except that is
On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wrote:
> We could also say that we will clean up the API when we move to Python
> 3. That is a natural breaking point anyway, so it will not any extra
> pain for users of the ZCA.
Except that is precisely what the Python developers have asked
ever
On 11/30/09 13:43 , Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli
> wrote:
>> Martijn Faassen wrote:
>>> This implies we don't want to release zope.component 4.0 for a long time
>>> yet.
>>
>> I think the answer should be "never". :)
>
> I think never is a rather long
Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli
> wrote:
>> Martijn Faassen wrote:
>>> This implies we don't want to release zope.component 4.0 for a long time
>>> yet.
>> I think the answer should be "never". :)
>
> I think never is a rather long time. I'd suggest we t
I find it rather odd that we're wasting so much time worrying about
backward incompatibility when we have a perfect mechanism to introduce
backward incompatible changes in a way that allows both flavours to be
used by packages in the same application (on a module by module basis
just like Martijn w
On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli wrote:
> Martijn Faassen wrote:
>> This implies we don't want to release zope.component 4.0 for a long time
>> yet.
>
> I think the answer should be "never". :)
I think never is a rather long time. I'd suggest we think about these
changes more in the
Martijn Faassen wrote:
> Martin Aspeli wrote:
>> Martijn Faassen wrote:
>>
>>> Multi-adaptation:
>>>
>>>IFoo(one, two)
>> Please note that this will break an incredible amount of code "in the
>> wild". A good number of my packages do something like this:
>>
>>foo = IFoo(context, None)
>>
Wolfgang Schnerring wrote:
> * Martijn Faassen [2009-11-27 12:32]:
>> Would people be okay with such an upgrade path? Any better ideas?
>
> Yes, I'm okay with it. I do think we should take care that the
> transition period is long enough, so that people have a chance to update
> their code. (The
Martin Aspeli wrote:
> Martijn Faassen wrote:
>
>> Multi-adaptation:
>>
>>IFoo(one, two)
>
> Please note that this will break an incredible amount of code "in the
> wild". A good number of my packages do something like this:
>
>foo = IFoo(context, None)
>if foo is None:
> ...
Chris McDonough wrote:
> Lennart Regebro wrote:
>>> I have very much
>>> come to appreciate the power of this delegation in, say, BrowserViews;
>>> even if it did take me several months to understand the multiadapter
>>> pattern!
>> I hear this a lot, so this is apparently something that is common
Charlie Clark wrote:
[snip]
> So adapters are reduced to type conversion?
Adaptation is "give me something that provides this API for this
object". Conversion in Python asks the same. Adaption just formalizes
this and generalizes it. I don't see how it's a reduction.
>> Calling an interface is
* Martijn Faassen [2009-11-27 12:32]:
> Are people okay with the proposed semantics?
+1, I think making these disappear into the language as much as possible
is a Good Thing(tm).
> Would people be okay with such an upgrade path? Any better ideas?
Yes, I'm okay with it. I do think we should take
Hello Hanno,
Seems that that was an adapter heavy app.
Was before the cut:
>>> len(getGlobalSiteManager()._utility_registrations)
980
>>> len(getGlobalSiteManager()._adapter_registrations)
1432
>>> len(getGlobalSiteManager()._handler_registrations)
63
>>> len(getGlobalSiteManager()._subsc
Martijn Faassen wrote:
> Multi-adaptation:
>
>IFoo(one, two)
Please note that this will break an incredible amount of code "in the
wild". A good number of my packages do something like this:
foo = IFoo(context, None)
if foo is None:
...
There is a lot of documentation out ther
On Sat, Nov 28, 2009 at 17:35, Charlie Clark
wrote:
> Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro :
>
>> That's what adapters are. They aren't reduced to it, it's what they
>> do. They adapt one object with one interface to have another
>> interface. That can indeed be seen as a type convers
Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro :
> That's what adapters are. They aren't reduced to it, it's what they
> do. They adapt one object with one interface to have another
> interface. That can indeed be seen as a type conversion.
I agree that that is probably the most common use for
Martijn Faassen wrote:
> Chris McDonough wrote:
>> Martijn Faassen wrote:
> [snip]
>>> 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 muc
Lennart Regebro wrote:
>> I have very much
>> come to appreciate the power of this delegation in, say, BrowserViews;
>> even if it did take me several months to understand the multiadapter
>> pattern!
>
> I hear this a lot, so this is apparently something that is common to
> take a while to grasp.
On Sat, Nov 28, 2009 at 16:39, Charlie Clark
wrote:
> So adapters are reduced to type conversion?
That's what adapters are. They aren't reduced to it, it's what they
do. They adapt one object with one interface to have another
interface. That can indeed be seen as a type conversion.
> Thanks for
Am 28.11.2009, 16:06 Uhr, schrieb Martijn Faassen :
>> I have to agree with this. IFoo(myobject) is not intuitive. I know it
>> used
>> a lot because it's convenient shorthand but I've never read anywhere
>> that
>> interface classes are, in fact, callables. We certainly don't normally
>> trea
Charlie Clark wrote:
> Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers :
>
>> Well, I don't think the difference between adapters and utilities is
>> important, but I can understand why some people find calling the
>> interface odd: it is when you think about it objectively.
>
> I have to agree w
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers :
> Well, I don't think the difference between adapters and utilities is
> important, but I can understand why some people find calling the
> interface odd: it is when you think about it objectively.
I have to agree with this. IFoo(myobject) is not
On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen
wrote:
> Adam GROSZER wrote:
>> 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 afte
Adam GROSZER wrote:
> 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.
Interesting. It'd be interesting to do some experiments
Tres Seaver wrote:
> -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
Chris McDonough wrote:
> Martijn Faassen wrote:
[snip]
>> 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.
>
> I sugges
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
-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
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.
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
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
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
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
1 - 100 of 111 matches
Mail list logo