On Tue, Dec 15, 2009 at 05:32:15PM -0500, Chris McDonough wrote:
> I wonder if maybe something like (notionally):
>
> class InterfaceBase(object):
> @classmethod
> def add_more_api(cls, **kw):
> cls.__dict__.update(kw)
I like this as a clear point to put a pdb when things do no
On Thu, Dec 17, 2009 at 04:59:12PM +0100, Thomas Lotze wrote:
> Martijn Faassen wrote:
> > Their behavior should be:
> >
> > IFoo.adapt(context) raises LookupError, unless the context provides IFoo,
> > in which case it returns context.
> >
> > IFoo.adapt(context, default=default) returns default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
schrieb Baiju M:
> On Fri, Dec 18, 2009 at 12:19 PM, Andreas Jung
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> schrieb Baiju M:
>>> Hi, In Zope 2 setup.py, the parameters of setup is defined as a
>>> separate dictionary and then unp
On Fri, Dec 18, 2009 at 12:19 PM, Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> schrieb Baiju M:
>> Hi,
>> In Zope 2 setup.py, the parameters of setup is defined as
>> a separate dictionary and then unpacked to setup function like this:
>>
>> setup(**params)
>>
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
schrieb Baiju M:
> Hi,
> In Zope 2 setup.py, the parameters of setup is defined as
> a separate dictionary and then unpacked to setup function like this:
>
> setup(**params)
>
> Any particular reason to do like this ?
>
>
Any particular problem?
Hi,
In Zope 2 setup.py, the parameters of setup is defined as
a separate dictionary and then unpacked to setup function like this:
setup(**params)
Any particular reason to do like this ?
Regards,
Baiju M
___
Zope-Dev maillist - Zope-Dev@zope.or
On Thu, Dec 17, 2009 at 9:53 PM, Marius Gedminas wrote:
> Could someone remind me if the bug happens during packing (and breaks
> the .tgz for everyone, which gets noticed and fixed soon) or during
> unpacking (and affects only a small percentage of users; those who still
> use python 2.4, and is
Hey,
Marius Gedminas wrote:
> I'd like to advance the following argument that I haven't seen yet in
> this thread: discoverability.
I was actually thinking very much about people who read the code all the
time, but apparently I wasn't very clear. That's also why I moved away
from a position
Marius Gedminas wrote:
[snip]
> So I'm -99 for magical side effects of import statements, but thankfully
> the community opinion is already against them.
Yeah, I was a bit too cavalier in earlier discussions about such a
solution. Tres suggested having a proper plugin API for this and a
registra
On Wed, Dec 16, 2009 at 04:53:58PM -0500, Tres Seaver wrote:
> Wichert Akkerman wrote:
> > On 2009-12-16 08:35, Baiju M wrote:
> >> Hi,
> >> Most of the source distribution packages of ZTK are
> >> in .tar.gz format. But there are few exceptions.
> >> For consistency, can we use .tar.gz forma
On Thu, Dec 17, 2009 at 05:48:04PM +0100, Martijn Faassen wrote:
> Thomas Lotze wrote:
> > I think looking at that API explains why we have trouble with having stub
> > methods defined by zope.interface: these methods contain enough
> > information about component concepts to blur the distinction b
On Thu, Dec 17, 2009 at 15:56, Martijn Faassen wrote:
> Is there a backwards compatibility import?
Nope. We could put one there, but I thought we might want to deprecate
it in zope.testing instead.
We can do both of course.
zope.testing.doctest and stdlibs doctest has grown apart a bit but I
don
On Wed, Dec 16, 2009 at 04:48:06PM -0500, Tres Seaver wrote:
> There is a perfectly reasonable "default"
> implementation anyway (in the absence of any hooks):
>
> - IFoo.adapt(context) raises LookupError, unless the context
> provides IFoo, in which case it returns context.
>
> - IFoo.adapt(co
Chris McDonough wrote:
> Martijn Faassen wrote:
>> Chris McDonough wrote:
>>> I'll throw out the obvious...
>>>
>>> Why not subclass Interface in zope.component and make the required API
>>> additions there? If it were anybody but us thinking about doing this,
>>> they'd
>>> probably just subcl
Martijn Faassen wrote:
> Chris McDonough wrote:
>> I'll throw out the obvious...
>>
>> Why not subclass Interface in zope.component and make the required API
>> additions there? If it were anybody but us thinking about doing this,
>> they'd
>> probably just subclass.
>
> Because then we'd need
Chris McDonough wrote:
> I'll throw out the obvious...
>
> Why not subclass Interface in zope.component and make the required API
> additions there? If it were anybody but us thinking about doing this, they'd
> probably just subclass.
Because then we'd need to rebase all our interfaces to be a
We've been through this option recently already. It has been quickly
shot down by those who want interfaces to get the new behaviour
immediately available in existing interfaces, instead of having to
rewrite already existing interfaces to support the new API.
Painful memories of a time when we had
Yeah, I was thinking that too, as a "I don't have time to think hard about
this" little daydream.
Actually I believe you would want to subclass InterfaceClass and make your new
zope.component.Interface an instance of the new InterfaceClass and specify
zope.interface's Interface as something i
I'll throw out the obvious...
Why not subclass Interface in zope.component and make the required API
additions there? If it were anybody but us thinking about doing this, they'd
probably just subclass.
- C
Martijn Faassen wrote:
> Wichert Akkerman wrote:
> [knip]
>> Perhapse LookupError shoul
Hey,
Thomas Lotze wrote:
[snip]
>> * We want to implement .adapter(), .utility() and .__call__() in
>> zope.component as much as possible.
>
> The method's name is `adapt`, JFTR.
Whoops, yes, I prefer 'adapt' actually anyway. :)
>> * we want a similar mechanism for each of them to plug in.
>
>
Wichert Akkerman wrote:
[knip]
> Perhapse LookupError should be a subclass of TypeError.
It's a Python built-in. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
Martijn Faassen wrote:
> Here's a summary of what has been going on in this thread with some
> attempts at conclusions that have support of the consensus so that Thomas
> can proceed
Thank you, half an hour later and I'd have written the summary ;o)
> * We want to implement .adapter(), .utility(
Hey,
Ethan Jucovy wrote:
> On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
> wrote:
>> * It'd be nice if __call__ came back with a LookupError instead of
>> a TypeError, but how to get from A to B without breakage?
>
> Maybe I've misunderstanding, but what's the advantage of making
> IFoo(x)
On 12/17/09 16:36 , Ethan Jucovy wrote:
> Hi,
>
> On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
> wrote:
>> * It'd be nice if __call__ came back with a LookupError instead of a
>> TypeError, but how to get from A to B without breakage?
>
> Maybe I've misunderstanding, but what's the advantage
Hi,
On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
wrote:
> * It'd be nice if __call__ came back with a LookupError instead of a
> TypeError, but how to get from A to B without breakage?
Maybe I've misunderstanding, but what's the advantage of making
IFoo(x) raise a LookupError instead of a T
Hi there,
Here's a summary of what has been going on in this thread with some
attempts at conclusions that have support of the consensus so that
Thomas can proceed
* We want to implement .adapter(), .utility() and .__call__() in
zope.component as much as possible.
* we want a similar mechanis
Lennart Regebro wrote:
> On Thu, Dec 17, 2009 at 02:53, Tres Seaver wrote:
>> I have checked in a branch which makes failed adaptation (inside the
>> __call__ of an interface) raise a LookupError instead of a TypeError:
>> the branch also documents the semantics of __call__. I would like to
>> me
On Thu, Dec 17, 2009 at 02:53, Tres Seaver wrote:
> I have checked in a branch which makes failed adaptation (inside the
> __call__ of an interface) raise a LookupError instead of a TypeError:
> the branch also documents the semantics of __call__. I would like to
> merge this to the trunk a 3.6.0
Martijn Faassen wrote:
> Hey,
>
> Tres Seaver wrote:
> [snip]
>> Any code today which wants a utility is calling 'getUtilty' (if it
>> *knows* the utility must be registered) or 'queryUtility' (if it thinks
>> it might not be). Less facetiously than my first challenge: please
>> point to actual
Christian Theune wrote:
[snip]
> If you'd like to see how the change looks like, you can look at the
> changes produced by running it on gocept.zope3instance [3][4].
I think these stack the wrong way around. The most recent copyright
owner should be on *top*, not on the bottom. Compare with blog
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Aspeli wrote:
>> Tres Seaver wrote:
>>
>>> In either case, I think TypeError (or maybe LookupError) is the *right*
>>> choice: we don't want to "hide" zope.component's API functions and then
>>> turn around and requir
Hey,
Tres Seaver wrote:
[snip]
> - -1 to any docstring / exception method which points outside the
> zope.itnerface package. There is a perfectly reasonable "default"
> implementation anyway (in the absence of any hooks):
You're against a docstring talking about zope.component overriding
these?
Summary of messages to the zope-tests list.
Period Wed Dec 16 12:00:00 2009 UTC to Thu Dec 17 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 16 20:38:28 EST 2009
URL: http://
Hey,
Tres Seaver wrote:
[snip]
> Any code today which wants a utility is calling 'getUtilty' (if it
> *knows* the utility must be registered) or 'queryUtility' (if it thinks
> it might not be). Less facetiously than my first challenge: please
> point to actual code in the wild which looks like::
Thomas Lotze wrote:
[snip]
> - The very concept of the ZCA introduces a related problem with code
> readability: just by reading the code that uses components you will
> never be able to tell where a particular adapter or utility comes from,
> or even what adapters or utilities you can hope t
Baiju M wrote:
> On Wed, Dec 16, 2009 at 9:23 PM, Chris Withers wrote:
>> Baiju M wrote:
>>>Most of the source distribution packages of ZTK are
>>> in .tar.gz format. But there are few exceptions.
>>> For consistency, can we use .tar.gz format for all releases ?
>> Why does anyone care? They
Hi,
after transferring the code ownership from ZC to the ZF we need to
change copyright headers in the repository.
I wrote a script [1][2] to help doing that (changing the trunks and last
two release branches) which is ready now.
This message is mainly intended as a heads-up: there'll be a lot
37 matches
Mail list logo
