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
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
On Tue, Dec 15, 2009 at 11:02, Christian Zagrodnick c...@gocept.com 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(
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,
On Tue, Dec 15, 2009 at 11:20, Wichert Akkerman wich...@wiggy.net 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:
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:
On 2009-12-15 11:20:19 +0100, Wichert Akkerman wich...@wiggy.net 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):
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 can
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 run
* Wolfgang Schnerring w...@gocept.com [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 try
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
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 -
On Tue, Dec 15, 2009 at 14:21, Marius Gedminas mar...@gedmin.as 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
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
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
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're
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
-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,
-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
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 TypeError instead of a
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 derive from
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 behavior
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
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.4
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 enough.
25 matches
Mail list logo
