Hey,
Marius Gedminas wrote:
> On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote:
>> On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas wrote:
>>> On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote:
3) [no] superfluous version bumps on the trunk
>>> I don't understand this one.
Thomas Lotze wrote:
> What's the oldest Python version the ZTK is supposed to support? 2.4?
> The ZTK docs don't seem to say anything about this.
Good point. I think right now the ZTK is supposed to support 2.4 to 2.6
(thanks to Jim's work in particular to fix it). I've added this to the
Zope To
Hey,
I think it would be good if we could (eventually) separate the Zope
Toolkit development documentation (what's published by
docs.zope.org/zopetoolkit now) from the Zope Toolkit release documentation.
Zope Toolkit dev documentation:
* aimed at people who need to *manage* the development of
Hey,
Stephan Richter wrote:
[snip]
> -1 from me too. Having the previous version avoids having to look it up in
> CHANGES.txt or the tags, which is really lame if you do lots of releasing.
From private conversations here at the Grok sprint with Christian I
think that means that the steering gr
Hi there,
Unless you think you have a great argument that you think will make
significant portions of the ZTK steering group change their mind on
this, this discussion should now be closed.
We're sticking with our current release policy for the ZTK packages.
This doesn't affect non-ZTK package
Thomas Lotze wrote:
> I asked about this before; let me do so again before assuming silence to
> mean consent:
>
> There's a PathPersistent class in zope.location.pickling which is
> decorated with a recent BBB comment, and had been questioned by a XXX
> comment for some time before that.
>
> The
Hey,
Christian Theune wrote:
> I'd like to suggest a redesign of the IReRaiseException.
>
> I found this when reviewing revision 103682 and stumbled over the naming
> of the interfaces and that the interface only mentions a __call__ to
> retrieve a fact.
>
> IMHO this pattern smells like we shou
Hey,
Christian Theune wrote:
>> This would be an interface on exceptions, right? Would it try to adapt
>> exceptions raised to IPublisherExceptionInfo and if successful look at
>> this attribute? So an exception can either implement this interface
>> directly, or you could register an adapter
Hi there,
Christian Theune wrote:
> I'm happy with that change, except that it might be worthwhile to
> announce policy changes in a separate thread.
Good point. I'll do that in the future; please remind again if it
doesn't happen.
Regards,
Martijn
Christian Theune wrote:
> On 09/18/2009 02:04 PM, Stephan Richter wrote:
>> On Friday 18 September 2009, Christian Theune wrote:
I've also taken the liberty to update the ZTK policy to say that this
should be done. (other steering group members can call me back if they
don't like thi
Hey,
Generally I believe that these rules if strictly applied wouldn't result
in a usable ZTK. Hanno already mentions the testing dependencies, which
we've barely started analyzing. Documentation in 'docs' would disqualify
just about any package (and Reinout brings up a few objections).
A numb
Hi there,
We now have in the ZTK repository also a facility to create dependency
graphs for the packages in the ZTK (thanks to Hanno's z3c.recipe.depgraph).
http://svn.zope.org/zopetoolkit/trunk/
See the README.txt for more information.
I reviewed some dependency graph for the ZTK the other da
Jim Fulton wrote:
> On Mon, Sep 21, 2009 at 11:19 AM, Martijn Faassen
> wrote:
>> Documentation in 'docs' would disqualify
>> just about any package (and Reinout brings up a few objections).
>
> I definitively want the option of making documentation executable.
Zvezdan Petkovic wrote:
> On Sep 21, 2009, at 11:42 AM, Martijn Faassen wrote:
>> * zope.minmax: is this package being used? If not, we could consider
>> removing it from the ZTK.
>
> It's easy to find that it's used by zope.session.
> It is used for conflict r
Jim Fulton wrote:
> On Mon, Sep 21, 2009 at 12:47 PM, Martijn Faassen
> wrote:
>> Jim Fulton wrote:
>>> On Mon, Sep 21, 2009 at 11:19 AM, Martijn Faassen
>>> wrote:
>>>> Documentation in 'docs' would disqualify
>>>> just a
Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> * zope.contenttype: we should analyze what is using zope.contenttype.
>
> Of the packages mentioned in ztk.cfg, zope.browserresource, zope.app.file
> and zope.app.onlinehelp are. There's also zope.mimetype which seems
Thomas Lotze wrote:
> I just noticed that zope.site depends on zope.app.publication, both via
> configure.zcml and the tests. The dependency isn't currently declared.
> On the other hand, zope.app.publication doesn't yet depend on zope.site.
>
> I'd like to get rid of the dependency of zope.site o
Hi there,
Albertas Agejevas wrote:
[snip]
> About a year ago zope.app.catalog as been moved to zope.catalog. I
> think during this move there was a unique opportunity to leave these
> event handlers behind in zope.app.catalog, so that the "no .app"
> version is free of these forced choices.
Do
Hey,
Thomas Lotze wrote:
[snip]
> I think I'll release the current zope.error later today so people get the
> benefit of the lighter dependencies.
Given you access to this too. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https:
Hey,
Thomas Lotze wrote:
[snip]
> Could someone with the appropriate privileges please grant me PyPI access
> to the two packages so I can make releases? (Though releasing zope.site
> might wait until another issue involving it has been resolved.)
I've given you access to both.
Regards,
Martijn
Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> Thanks for doing this analysis! It'd be great if you could turn this into
>> a proposal for future actions...
>
> Do you mean a proposal that would go in the "Proposals" section of the ztk
> docs?
A
Albertas Agejevas wrote:
> On Tue, Sep 29, 2009 at 01:09:08PM +0200, Martijn Faassen wrote:
>>> About a year ago zope.app.catalog as been moved to zope.catalog. I
>>> think during this move there was a unique opportunity to leave these
>>> event handlers behind in
Thomas Lotze wrote:
> Having worked on and released new versions of a few ZTK packages recently,
> I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as
> there doesn't seem to be an agreed process about this and in an attempt
> not to step on anyone's toes, I'd like to ask first
Hey,
Hanno Schlichting wrote:
[snip]
> I don't see how a ZTK meta-egg would be of any value. Given that the
> number of packages included in the ZTK will change quite a bit over
> time, it doesn't make sense to depend on a ZTK egg for a package, as
> it doesn't provide any real stable contract. An
Thomas Lotze wrote:
[snip]
> - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a
> versioned URL
I agree we should make it available under a versioned URL somehow.
Whether ztk.cfg can be reused directly or whether we should extract
something in it with just the version ind
Hey,
Thomas Lotze wrote:
> zope.site.hooks is a rather light-weight module that is concerned with
> the concept of a current site, where the notion of a site is used in the
> same sense as in zope.component, which actually prefers to only talk
> about a component registry. In contrast, the rest of
Hey,
Yay! Zope's caveman spin-off, Grok, finally got its 1.0 release today!
http://grok.zope.org
Thanks should also go to all Zope hackers for helping to provide the
foundation for Grok!
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Jim Fulton wrote:
[snip]
> In any case, I agree it should be dropped from the ZTK.
+1 on dropping it too.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML enc
Tim Hoffman wrote:
> On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli
> wrote:
>> Martijn Faassen wrote:
>>
>>
>> Please don't add new dependencies to zope.component. Even optional ones,
>> IMHO. It makes it harder to re-use for others and more complex
Hanno Schlichting wrote:
>> On Mon, Oct 5, 2009 at 1:18 PM, Martin Aspeli
>> wrote:
>> Fabio Tranchitella wrote:
>>> * 2009-10-05 12:15, Martin Aspeli wrote:
Would anyone mind making a 3.5.1 release, or else give me PyPI rights so
that I can do it myself.
>>> Shouldn't this be 3.6.0?
>>
Hi there,
To quote Thomas Lotze in another discussion:
> [ztk.cfg] contains a line
> allow-picked-versions = false
> which makes buildout complain if it ends up using a package whose
> version it had to pick from the index, so you're required to specify a
> version for every package used b
Hey,
Thomas Lotze wrote:
[snip]
> I mentioned the zcml extra only because that's how zope.component has to
> do with the security concept already, as a motivation of why I'm letting
> go of my opposition to introducing more of that concept into
> zope.component.
I think it would be interesting to
Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> Whether ztk.cfg can be reused directly or whether we should extract
>> something in it with just the version indicators I'm not sure about. I've
>> noticed when modifying the buildout.cfg of the ZTK to add
>>
Martin Aspeli wrote:
> Hanno Schlichting wrote:
>> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen
>> wrote:
>>> > [ztk.cfg] contains a line
>>>
>>> > allow-picked-versions = false
>>>
>>> I agree with Thomas that we shoul
Martin Aspeli wrote:
> Martin Aspeli wrote:
>
>> Right, sorry, I must've been tired when I read this. In my mind, I read
>> it as "disallow-picked-versions = false". :)
>
> No, I'm not crazy after all. The thread is about *removing*
> "allow-picked-versions=false" i.e. allowing versions to be p
Tarek Ziade wrote:
> Log message for revision 104933:
> comparing requirement locations instead of requirement objects
Did I miss the CHANGES.txt update?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/list
Fabio Tranchitella wrote:
[snip]
> All the proxying stuff can be made optional with conditional imports.
> I think the only solution to make zope.security optional without
> removing the "permission" attribute is to do something like:
> try:
>from zope.security.zcml import Permission
> e
Fabio Tranchitella wrote:
[snip]
> Anyway, I'm fine with what Martijn proposed if nobody else supports my
> idea.
I'm okay with *not* doing the split up and going with your idea, but I
think eventually such a split up would simplify things. One advantage
would be that someone could examine repoz
Hey,
Fabio Tranchitella wrote:
[snip]
> I tried to implement my idea here:
>
>
> svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security
>
> This is a quite intrusive change, so please take it as a "suggestion" and
> not as a real proposal: is this the right approach?
Thomas Lotze wrote:
> Thomas Lotze wrote:
>
>> While writing tests for the zope.site.hooks module I'm moving to
>> zope.component, I notice that the module calls getSiteManager() on an site
>> object. Such an object isn't technically required to implement an
>> interface that declares that method,
Chris McDonough wrote:
> So were any Zope talks/tutorials accepted?
I have no idea, besides BFG, which is at the very least Zope related. :)
Lennart?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/
Hey,
Fabio Tranchitella wrote:
> Anyone willing to make a new release of zope.component and zope.sendmmail,
> or give me the pypi access to do it?
What's your pypi username?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.
Fabio Tranchitella wrote:
> Hello,
>
> * 2009-11-16 10:25, Martijn Faassen wrote:
>>> Anyone willing to make a new release of zope.component and zope.sendmmail,
>>> or give me the pypi access to do it?
>> What's your pypi username?
>
> kobold
I'
exar...@twistedmatrix.com wrote:
> Hi,
>
> I've just contributed a patch to CPython adding os.initgroups based on
> this extension module:
>
> http://svn.zope.org/Zope/trunk/src/initgroups/
>
> The CPython ticket is here:
>
> http://bugs.python.org/issue7333
>
> I don't think there should
exar...@twistedmatrix.com wrote:
> I don't think there should be any licensing issues, as the ZPL is pretty
> permissive and the code is very short. However, if there are, could the
> code in question be relicensed for CPython under the Python license?
That was 4 out of 7 board members replying
Hi there,
Reading the thread Chris McDonough started (and ended) about modifying
the way utility registration works reminded me of the following
thinking. It's quite independent and probably even antithetical to
Chris's approach as it uses interfaces, but that's fine.
The goal is to make it ea
Thomas Lotze wrote:
[snip]
> What about a simple and consistent API for all components including
> utilities, adapters and multiadapters:
>
> IFoo()
> IFoo(x)
> IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
Regards,
Marti
Hey,
Jan-Wijbrand Kolman wrote:
> I'm about to work a bit on z3c.schema2json [1]. As has been briefly
> discussed before (a while ago [2]), z3c. schema2json is so similar to
> z3c.schema2xml [3] in what it does and how it does it, that I wonder
> about merging the two packages somehow.
>
> One
Thomas Lotze wrote:
> Martijn Faassen wrote:
>
>> Thomas Lotze wrote:
>> [snip]
>>> What about a simple and consistent API for all components including
>>> utilities, adapters and multiadapters:
>>>
>>> IFoo()
>>> IFoo(x)
>>>
;
> I quite like the simplicity of this spelling, so I want to be sure
> *why* it must be ruled out. (...or does it, really?)
>
> I'm thinking that this...
>
> * Martijn Faassen [2009-11-25 22:21]:
>> The last one won't work if we want to maintain backwar
Shane Hathaway wrote:
[I talk about backwards compatibility issues with some proposed API changes,
but this modification doesn't have this issue]
> Here is an interface decorator I intend to try out soon. It adds
> convenient component lookup methods to a particular interface without
> requirin
Thomas Lotze wrote:
[snip]
> Then let me suggest not changing the call signature of an interface at all
> but only add one or a few new methods. Firstly, this will keep backwards
> compatibility even with code that adapts a tuple, and secondly, it allows
> us to implement a simple and consistent AP
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
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
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)
&
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
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
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
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 in
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
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
Chris McDonough wrote:
[snip]
> It tries to address the following problem.
>
> Currently people seem to get wrapped around the axle and confused by the
> purpose of "the ZCA", which currently implies at least two different things:
>
> - Machinery to perform complex registrations and lookups usin
Chris McDonough wrote:
> 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 noti
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
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
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
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:
>
>
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 up
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
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
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 weeken
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
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://
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
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 w
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
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.
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
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
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
Hi there,
I'd like to summarize the options I've seen appear in the discussion so far.
We have the following options:
1) introduce a new method, such as "instance()" or "lookup()" on
instance. It unifies utilities with adapters. We can make it do whatever
we want without worrying about backwar
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
Martin Aspeli wrote:
> Can you summarise what you mean by this? The thread is so long...
[snip]
> My brain hurts... examples?
[snip]
> I'm afraid you've lost me. Four ways sounds bad, though. ;-)
I've edited down and clarified what I posted earlier.
First a statement about the goal of this discu
Chris McDonough wrote:
> Personally I think that it's a fantasy to believe that the difference between
> an object created via a factory on-demand and an object simply returned
> should
> *never* matter to a caller. You may not want the caller to need to care, and
> it may be inconvenient to t
Hey,
Chris McDonough wrote:
[snip]
> If you want to create a world where callers never need to care about the
> lifetime of any object returned by a component lookup, you could also return
> a
> proxy wrapper around the returned object that only allows for the invocation
> of
> the methods de
Gary Poster wrote:
> You are leaving out the variants of 3 and 4 that allow calling the
> interface to support multiadaptation, but do not unify utilities.
True, my mistake. Lennart pointed that out too just now.
> My impression is that I am not the only one who is not pleased with
> the propose
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
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 tu
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
_
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
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
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 wi
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
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 rej
501 - 600 of 1205 matches
Mail list logo
