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
Baiju M wrote:
On Wed, Dec 16, 2009 at 9:23 PM, Chris Withers ch...@simplistix.co.uk 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
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 to
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:
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?
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 require folks to import
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
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 code in the
On Thu, Dec 17, 2009 at 02:53, Tres Seaver tsea...@palladion.com 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
Lennart Regebro wrote:
On Thu, Dec 17, 2009 at 02:53, Tres Seaver tsea...@palladion.com 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
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
Hi,
On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
faas...@startifact.com 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
On 12/17/09 16:36 , Ethan Jucovy wrote:
Hi,
On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
faas...@startifact.com 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
Hey,
Ethan Jucovy wrote:
On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
faas...@startifact.com 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
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()
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
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.
Agreed,
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 should
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 it
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
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 able
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 to rebase all
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 subclass.
Because then
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(context,
On Thu, Dec 17, 2009 at 15:56, Martijn Faassen faas...@startifact.com 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
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 between
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 format for all
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
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
On Thu, Dec 17, 2009 at 9:53 PM, Marius Gedminas mar...@gedmin.as 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
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 -
-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? I think
On Fri, Dec 18, 2009 at 12:19 PM, Andreas Jung li...@zopyx.com 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:
On Fri, Dec 18, 2009 at 12:19 PM, Andreas Jung li...@zopyx.com
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
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 unless
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 not go
36 matches
Mail list logo
