On 12/15/2009 11:32 PM, Tres Seaver wrote:
> Given that the choice to use __call__ is not widely enough accepted, I
> think something like your solution makes sense. I'm not sure that
> hooking __getattr__ is going to be performant enough, but a similar
> mechanism probably could be made fast enou
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 releases ?
Once there is a python 2.4 release which fixes the tarfile bug, or once
python 2
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 releases ?
PEP 8: A Foolish Consistency is the Hobgoblin of Little Minds
Regards,
Baiju M
__
Martijn Faassen wrote:
>> * The hook invokes the `query*` functions to play nice with any other
>> component hooks and the interface methods raise a TypeError if all of
>> them fail to find a component.
>
> A TypeError instead of a ComponentLookupError?
>
> I was thinking we should keep the
Tres Seaver wrote:
>>> +1 to TypeError: nobody really cares about the type of the error: code
>>> that wants to be robust about a failure uses the 'query' methods. As
>>> long as the message is informative enough (which ComponentLookupError
>>> isn't, really) we should be fine. If we made CLE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
> Tres Seaver wrote:
>
* The hook invokes the `query*` functions to play nice with any other
component hooks and the interface methods raise a TypeError if all of
them
fail to find a component.
>>> A Typ
Tres Seaver wrote:
>>> * The hook invokes the `query*` functions to play nice with any other
>>>component hooks and the interface methods raise a TypeError if all of
>>> them
>>>fail to find a component.
>> A TypeError instead of a ComponentLookupError?
>>
>> I was thinking we should keep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
> Log message for revision 106536:
> Include distribute, so we can use it in presence of the
> allow-picked-versions=false
>
>
> Changed:
> U zopetoolkit/trunk/ztk.cfg
>
> -=-
> Modified: zopetoolkit/trunk/ztk.cfg
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hey,
>
> Good to see there's progress!
>
> Thomas Lotze wrote:
> [snip]
>> Except that I don't like the implications now that I have actually written
>> down the code. I'll describe the problem I see and then suggest an idea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leonardo Rochael Almeida wrote:
> Funny you should mention this, I've got this idea bugging for a few
> weeks now, after the last thread:
>
> Have the zope.interface package expose a single overridable hook:
>
> def getInterfaceAttribute(iface, name,
I wonder if maybe something like (notionally):
class InterfaceBase(object):
@classmethod
def add_more_api(cls, **kw):
cls.__dict__.update(kw)
- C
Leonardo Rochael Almeida wrote:
> Funny you should mention this, I've got this idea bugging for a few
> weeks now, after the last
Hey,
Good to see there's progress!
Thomas Lotze wrote:
[snip]
> Except that I don't like the implications now that I have actually written
> down the code. I'll describe the problem I see and then suggest an idea that I
> don't think we've been considering in the discussion two weeks ago:
>
> We
Funny you should mention this, I've got this idea bugging for a few
weeks now, after the last thread:
Have the zope.interface package expose a single overridable hook:
def getInterfaceAttribute(iface, name, default):
This method would be called by any attempt to look up an interface
attribute th
Am Dienstag 15 Dezember 2009 17:16:12 schrieb Thomas Lotze:
> So we've decided to let interfaces grow `adapt` and `utility` methods. I've
> written a simple and straight-forward implementation of them (see the
> tlotze-component-API branches of zope.interface and zope.component) that is
> closely m
On Tue, Dec 15, 2009 at 14:21, Marius Gedminas wrote:
> On Tue, Dec 15, 2009 at 10:22:03AM +0100, Lennart Regebro wrote:
>> And now it's zc.buildout. It also uses itself, to set up the
>> environment so that you can test it. I did try using distribute
>> instead, but I get strange inconsistent err
Hi all,
I just re-released zc.recipe.wrapper. The previous release lacked a
corresponding svn tag. This release fixes that, and should be
otherwise unremarkable.
--
Alex Smith
Software Engineer
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zop
So we've decided to let interfaces grow `adapt` and `utility` methods. I've
written a simple and straight-forward implementation of them (see the
tlotze-component-API branches of zope.interface and zope.component) that is
closely modelled on the exisiting `__call__`. In particular, the new methods
* Wolfgang Schnerring [2009-12-07 08:53]:
>>> The minimal reproduction recipe to see the error is this:
>>>
>>> class Slotted(object):
>>> __slots__ = ('__provides__')
>>>
>>> zope.component.provideAdapter(
>>> lambda x: True, (Slotted,), zope.interface.Interface)
> I'll
On 12/15/09 2:21 PM, Marius Gedminas wrote:
> If I weren't extremely hungry and starving, I'd run the tests in the official
> fashion (bin/buildout&& bin/test) and see if I get the same failures.
Be sure to look at DEVELOPERS.txt in the root (you need pythons without
setuptools and you need to r
On Tue, Dec 15, 2009 at 10:22:03AM +0100, Lennart Regebro wrote:
> And now it's zc.buildout. It also uses itself, to set up the
> environment so that you can test it. I did try using distribute
> instead, but I get strange inconsistent errors, different ones each
> time I try. :-/
>
> If someone c
On 2009-12-15 11:20:19 +0100, Wichert Akkerman said:
> On 12/15/09 11:02 , Christian Zagrodnick wrote:
>> Hi,
>>
>> to get generations working in Zope 2 the following subscriber is needed:
>>
>> @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent)
>> def evolve_minimum(event):
>> zo
Summary of messages to the zope-tests list.
Period Mon Dec 14 12:00:00 2009 UTC to Tue Dec 15 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: Mon Dec 14 20:38:30 EST 2009
URL: http://
On Tue, Dec 15, 2009 at 11:20, Wichert Akkerman wrote:
> -1, this would add a needless dependency on zope.app.generations to Zope
> 2 as far as I can see.
Good point. The lack of imports tricked me into thinking this was
easier than it was. :)
--
Lennart Regebro: http://regebro.wordpress.com/
P
On 12/15/09 11:02 , Christian Zagrodnick wrote:
> Hi,
>
> to get generations working in Zope 2 the following subscriber is needed:
>
> @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent)
> def evolve_minimum(event):
> zope.app.generations.generations.evolve(
> Zope2.DB, z
On Tue, Dec 15, 2009 at 11:02, Christian Zagrodnick wrote:
> Hi,
>
> to get generations working in Zope 2 the following subscriber is needed:
>
> @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent)
> def evolve_minimum(event):
> zope.app.generations.generations.evolve(
> Zop
Hi,
to get generations working in Zope 2 the following subscriber is needed:
@zope.component.adapter(zope.app.appsetup.IProcessStartingEvent)
def evolve_minimum(event):
zope.app.generations.generations.evolve(
Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM)
I think should
And now it's zc.buildout. It also uses itself, to set up the
environment so that you can test it. I did try using distribute
instead, but I get strange inconsistent errors, different ones each
time I try. :-/
If someone can set up a way of running the tests for zc.buildout
without using zc.buildou
27 matches
Mail list logo
