Re: [Zope-dev] zope-tests - FAILED: 4, OK: 8
On Tue, Sep 10, 2013 at 09:32:18AM +0300, Marius Gedminas wrote: > On Mon, Sep 09, 2013 at 12:26:33PM -0400, Tres Seaver wrote: > > On 09/09/2013 11:53 AM, Marius Gedminas wrote: > > > On Sat, Sep 07, 2013 at 08:27:04PM -0400, Tres Seaver wrote: > > >> On 09/07/2013 07:00 PM, Zope tests summarizer wrote: > > >>> [1]FAILED winbot / zope.app.authentication_py_265_32 > > >>> https://mail.zope.org/pipermail/zope-tests/2013-September/078621.html > > >>> [2]FAILED winbot / zope.app.http_py_265_32 > > >>> https://mail.zope.org/pipermail/zope-tests/2013-September/078622.html > > >>> [3]FAILED winbot / zope.app.publication_py_265_32 > > >>> https://mail.zope.org/pipermail/zope-tests/2013-September/078620.html > > >>> [4]FAILED winbot / zope.app.wsgi_py_265_32 > > >>> https://mail.zope.org/pipermail/zope-tests/2013-September/078623.html > > >>> > > All four show the same failure in the bulidout phase: > > >> > > >> %< --- > > >> While: Installing test. Error: There is a version conflict. We > > >> already have: webtest 2.0.7 > > >> %< --- > > > > > > Could be my fault. I released zope.testbrowser 4.0.3 to PyPI a few > > > days ago, and it has install_requires = ['WebTest <= 1.3.4']. > > > > > > OTOH it wasn't me who added that <= constraint, that happened a year > > > ago: > > > https://github.com/zopefoundation/zope.testbrowser/commit/699a18bb2868d23cd7ab3da80cf394b75f977d91 > > > > > > I just made a release with all the accumulated changes. > > > > Looks like that was Adam: maybe we should be trying to push out a > > version of z.tb compatible with current WebTest? > > IIRC there's a brand new zope.testbrowser 4.1.0 with Python 3 support, > built on top of WebTest, waiting in the py3 branch for... Actually, I'm > not sure what it is waiting for. (I thought ZODB with Python 3 support, > but it doesn't look like zope.testbrowser depends on ZODB, at least not > directly.) Indeed, and it's had no changes for at least 5 months and been tested with a few existing codebases. +1 for releasing it > > Andrey? > > Marius Gedminas > -- > http://pov.lt/ -- Zope 3/BlueBream consulting and development > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Wed, Apr 17, 2013 at 11:15:35PM +0300, Andrey Lebedev wrote: > On 04/15/2013 01:42 PM, Brian Sutherland wrote: > >> Great! Now, as all our webtest fixes are released upstream, I plan > >> to make an alpha release of what we've done so far. If you have any > >> outstanding issues with new testbrowser, please report. > > > >Just committed the last two. Sorry for the drip feed, but it takes a > >while to make simple test cases from the failures I see in my app. > > Just fixed those. Great, I've just confirmed that I have no more test failures in my app caused by bugs in the new testbrowser. I've found two that are bugs in the old testbrowser though, where tests passed by mistake ;) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Sat, Apr 13, 2013 at 12:54:22AM +0300, Andrey Lebedev wrote: > On 04/12/2013 02:59 PM, Brian Sutherland wrote: > >This is looking very very good, in my app very few tests are still > >failing. > > Great! Now, as all our webtest fixes are released upstream, I plan > to make an alpha release of what we've done so far. If you have any > outstanding issues with new testbrowser, please report. Just committed the last two. Sorry for the drip feed, but it takes a while to make simple test cases from the failures I see in my app. +1 to an alpha release soon. > >I poked around at one and found that the way non-ascii in forms is > >handled has changed under python 2, here's a test that shows the > >problem: > > > > > > https://github.com/zopefoundation/zope.testbrowser/commit/e0e965086c7fded415963518a6adef41b9d14619 > > Thanks, I've fixed the testbrowser according to your testcase. perfect > >I'm not sure what the intention of the python 3 port is wrt unicode. > >Have you had any thoughts on the matter? > > The idea is to make testbrowser to return/accept native strings > instead of bytes/unicode for both py2 and py3. Under py2, controls > will return str objects (for backwards compatibility), and under py3 > that would be unicode strings (for usage convenience). I guessed correctly then :) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Tue, Mar 19, 2013 at 04:40:02PM +0200, Andrey Lebedev wrote: > On 03/04/2013 08:40 PM, Andrey Lebedev wrote: > > > >As you may already know, there is an effort to port zope packages to > >Python 3 going on. As part of this effort we want to port zope.testbrowser. > > Status update: test suite passes on webtest backend under > python-2.6, 2.7 and 3.3. > > Further things to do: make some performance improvements, try some > real-world tests and release a alpha version. This is looking very very good, in my app very few tests are still failing. I poked around at one and found that the way non-ascii in forms is handled has changed under python 2, here's a test that shows the problem: https://github.com/zopefoundation/zope.testbrowser/commit/e0e965086c7fded415963518a6adef41b9d14619 I'm not sure what the intention of the python 3 port is wrt unicode. Have you had any thoughts on the matter? -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Tue, Mar 19, 2013 at 04:40:02PM +0200, Andrey Lebedev wrote: > On 03/04/2013 08:40 PM, Andrey Lebedev wrote: > > > >As you may already know, there is an effort to port zope packages to > >Python 3 going on. As part of this effort we want to port zope.testbrowser. > > Status update: test suite passes on webtest backend under > python-2.6, 2.7 and 3.3. > > Further things to do: make some performance improvements, try some > real-world tests and release a alpha version. I tried it against my app with good results so far :) I did notice two regression and pushed failing tests to you py3 branch. It seemed the easiest/fastest way forward, if you'd rather I made a separate branch for these, let me know. > > > -- > Andrey Lebedev aka -.- . -.. -.. . .-. > Software engineer > Homepage: http://lebedev.lt/ > Jabber ID: ked...@jabber.ru > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Tue, Mar 05, 2013 at 06:49:35PM +0200, Andrey Lebedev wrote: > On 03/05/2013 06:45 PM, Brian Sutherland wrote: > >One thing which I'm not sure you can do with a webtest backend is using > >it as a real browser. i.e. you'll probably not get over_the_wire.txt to > >pass. However, I don't know of anyone who actually uses that > >functionality. > > Hm, webtest claims it can do this [1], but I haven't tested it myself yet. > > [1] > http://webtest.pythonpaste.org/en/latest/testapp.html#testing-a-non-wsgi-application Nice! -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Tue, Mar 05, 2013 at 05:56:54PM +0200, Andrey Lebedev wrote: > On 03/05/2013 05:10 PM, Brian Sutherland wrote: > >>So far, it seems webtest has all the features needed to do the > >>>switch. I started a branch at github ([2]) to track work in > >>>progress. The goal is to make most (say 80%) of existing tests to > >>>work without modifications under new implementation. > > >Looking at the branch, it seems that this is basically going to be a > >re-write of the existing code. > > Yes, it is a re-write, but not re-write from scratch. I use existing > code as much as possible. > > >You're planning to keep the mechanize backend available? > > Initially we didn't plan to keep mechanize. I think it would add an > unjustified burden of choice to users (which backend to pick, if > they work the same way?) and mechanize backend will/may not work in > python3 anyway. > > The question of how compatible the webtest-based implementation will > be, is still an open one though. However, we have a big real-world > project to test compatibility against. You're right, the big question is how compatible the WebTest version will be. I don't think anyone will object to a drop-in replacement. Having to modify 20% of existing tests sounds like a lot. I guess we'll have to see how compatible the new browser will be. I'm willing to pitch in by testing it against my own application, please let me know when/if you want me to do that. > >Might I suggest zope.testbrowser.webtest for the WebTest backed > >testbrowser rather than zope.testbrowser.browser2? > > I admit there is a bit of mess right now in the branch as I need to > preserve existing code to copy when applicable. My plan is to rename > z.t.browser2 to z.t.browser eventually, so it is not a final name. Ok! > >Could you also keep the tests for the mechanize testbrowser intact? > >They could be skipped if mechanize is not importable and mechanize > >downgraded to an optional dependency. > > Again, if the compatibility of new implementation is proven to be > "good enough", I see no reason to keep mechanize around. I might > miss some important reasons, though. One thing which I'm not sure you can do with a webtest backend is using it as a real browser. i.e. you'll probably not get over_the_wire.txt to pass. However, I don't know of anyone who actually uses that functionality. Hmm, though I guess you can have a WSGI application that fires off real HTTP requests... -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize
On Mon, Mar 04, 2013 at 08:40:23PM +0200, Andrey Lebedev wrote: > Hello zope-dev, > > As you may already know, there is an effort to port zope packages to > Python 3 going on. As part of this effort we want to port > zope.testbrowser. Great! I'm very interested in this, I've also got an app which I'll need to port to python3 at some time. > Unfortunately, mechanize package, that zope.testbrowser depends on > has no py3 support. There is an unfinished effort at [1], however, > after closer examination of the codebase and state of the port, it > seems more practical to switch internal implementation of > zope.testbrowser to webtest. > > So far, it seems webtest has all the features needed to do the > switch. I started a branch at github ([2]) to track work in > progress. The goal is to make most (say 80%) of existing tests to > work without modifications under new implementation. Looking at the branch, it seems that this is basically going to be a re-write of the existing code. You're planning to keep the mechanize backend available? Might I suggest zope.testbrowser.webtest for the WebTest backed testbrowser rather than zope.testbrowser.browser2? Could you also keep the tests for the mechanize testbrowser intact? They could be skipped if mechanize is not importable and mechanize downgraded to an optional dependency. > [1] http://web.cecs.pdx.edu/~adevore/mechanize/ > [2] https://github.com/zopefoundation/zope.testbrowser/tree/webtest > > -- > Andrey Lebedev aka -.- . -.. -.. . .-. > Software engineer > Homepage: http://lebedev.lt/ > Jabber ID: ked...@jabber.ru > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security
> On 02/11/2013 03:36 PM, Stephan Richter wrote: > > Hi Tres (and everyone else reading along), > > > > as you are probably aware, zope.security is a package that blocks a > > lot of other packages from being ported. I just checked out the > > coverage on Github and it looks like you are making good progress. > > > > The biggest issue I see with zope.security is its dependency on > > RestrictedPython, because I think that will take a long time to port > > correctly. However, most of zope.security is very much usable and used > > without zope.security.untrustedpython. > > > > I propose to split zope.security.untrustedpython into a separate > > package called zope.untrustedpython, so that a port of zope.security > > to Python 3 can move forward. (Note: I am signing up for the work.) +1 ! -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to signal that projects have moved to github
On Thu, Jan 10, 2013 at 09:15:21AM -0500, Jim Fulton wrote: > I'd like us to agree on how we're going to indicate in SVN > that projects have been moved to github. > > Here's an opening bid: > > - Replace contents of trunk with a single file MOVED_TO_GITHUB > containing the URL if the project page in github > > - Copy above file to root of project. > > - Make project read only +1 > An argument against cleaning out trunk will break > CI tools. This is also an argument *for* cleaning > out trunk. :) Maybe a bit draconian at this stage? This could perhaps be done much later in the migration by scripting the removal of all trunks with a MOVED_TO_GITHUB file. > Thoughts? > > There are a lot of other details of the migration that need > to be worked out, like how folks should request migration and > automating the conversion further. > > Jim > > -- > Jim Fulton > http://www.linkedin.com/in/jimfulton > Jerky is better than bacon! http://zo.pe/Kqm > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface 4.0.0 considered annoying.
On Sun, May 20, 2012 at 12:08:14AM -0400, Tres Seaver wrote: > On 05/19/2012 07:23 PM, Jim Fulton wrote: > > On Sat, May 19, 2012 at 5:59 PM, Tres Seaver > > wrote: > >> On 05/19/2012 12:12 PM, Jim Fulton wrote: > >>> The declaration-syntax warnings in the zope.interface 4.0.0 are > >>> annoying and mostly pointless. > >>> > >>> There will be enough pain in porting applications to Python 3, > >>> avoiding the surprise of having to use a different > >>> interface-declaration syntax will not be of any consequence. > >>> > >>> While the deprecation warning may provide some tiny benefit, the > >>> annoyance, especially for applications or libraries that still > >>> support Python 2.5 far outweights the benefit. > >> > >> We're in an odd spot: the Python3 support for zope.interface > >> mostly works, but the class advice bits (implements, > >> implementsOnly, classProvides) fail silently under Python3 before > >> 4.0.0: they literally have no effect due to changes in class > >> initialization machinery. zope.interface 4.0.0 changes those silent > >> failures into exceptions (which is what I thought you were going to > >> complain about). > > > > I'd forgotten the fail silently bit. Can't we make the fail loudly > > for Python 3? > > They already do: 4.0.0 makes them exceptions under Python3: that fact > was actually my rationale for the warnings under Python2, to allow folks > to find and remediate them before porting. > > I will release a 4.0.1 silencing the warnings unless somebody speaks up > in their favor. +1 to silencing the warnings under Python 2 -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 3.3 port of zope.configuration
On Fri, May 04, 2012 at 07:50:57PM -0400, Tres Seaver wrote:
> On 04/26/2012 02:34 PM, Tres Seaver wrote:
> > On 04/26/2012 01:50 PM, Brian Sutherland wrote:
> >> On Thu, Apr 26, 2012 at 12:06:13PM -0400, Tres Seaver wrote: On
> >> 04/26/2012 04:39 AM, Brian Sutherland wrote:
> >>>>> On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
> >>>>>> Also, do your branches still pass tests on 3.2.x? I'm sort
> >>>>>> of keen to see both zope.schema and zope.configuration join
> >>>>>> the "2to3-free" camp with zope.event, zope.interface,
> >>>>>> zope.i18nmessageid, and zope.exceptions (yes,
> >>>>>> zope.configuration, I'm looking at you next).
> >>>>>
> >>>>> I see you've started doing this in a better and more rigorous
> >>>>> way than I was. So I'm going to abandon my plans to merge in
> >>>>> favour of your branches.
> >>>>>
> >>>>> I'd still urge you to have a look at my zope.schema branch,
> >>>>> which I think solves a real problem with URI fields and
> >>>>> Python 3. The patch is pretty small.
> >
> >> My zope.schema branch is largely focused on improving the unittest
> >> coverage, while also making the package work with Python 3.2 (i.e.,
> >> not relying on 3.3's restoration of unicode literals).
> >
> >> I would be glad to look at your branch; I had already considered
> >> making the "native string" fields APIs. I'm not sure that I agree
> >> that the ASCII / URI / Id / DottedName fields should have native
> >> string as its type: can you help by elaborating there?
> >
> >>> For DottedName we're basically forced to use native strings as
> >>> you can import modules with unicode names on python 3:
> >
> >>>>>> from 漢語 import Español print(Español)
> >>>
> >
> >>> Id is either a URI or a DottedName. So it must, like DottedName,
> >>> also be a native string.
> >
> >>> As for URI, python 3 library functions seem to not care, so we can
> >>> choose either:
> >
> >>>>>> from urllib.parse import urlparse
> >>>>>> urlparse('http://www.example.com/unicode')
> >>> ParseResult(scheme='http', netloc='www.example.com',
> >>> path='/unicode', params='', query='', fragment='')
> >>>>>> urlparse(b'http://www.example.com/bytes')
> >>> ParseResultBytes(scheme=b'http', netloc=b'www.example.com',
> >>> path=b'/bytes', params=b'', query=b'', fragment=b'')
> >
> >>> But, for consistency's sake, URI, Id and DottedName should be the
> >>> same. That makes the best choice for URI a native string.
> >
> >>> Another more practical argument is that having URI be a "native
> >>> string" made the porting of zope.configuration to python 3 much
> >>> easier. There were a few nasty bugs when trying it with URI as
> >>> bytes.
> >
> >>> I have no strong argument for ASCII.
> >
> >>> FWIW, here's the original discussion on porting zope.schema:
> >>> https://mail.zope.org/pipermail/zope-dev/2011-October/043540.html
> >
> > Thanks very much for the explanation. I will plan to merge in your
> > changes in my branch ASAP.
>
>
> Done and merged to the trunk with my 'test_cleanup' branch.
Looks great, thanks!
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 3.3 port of zope.configuration
On Thu, Apr 26, 2012 at 12:06:13PM -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/26/2012 04:39 AM, Brian Sutherland wrote:
> > On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
> >> Also, do your branches still pass tests on 3.2.x? I'm sort of keen
> >> to see both zope.schema and zope.configuration join the "2to3-free"
> >> camp with zope.event, zope.interface, zope.i18nmessageid, and
> >> zope.exceptions (yes, zope.configuration, I'm looking at you next).
> >
> > I see you've started doing this in a better and more rigorous way than
> > I was. So I'm going to abandon my plans to merge in favour of your
> > branches.
> >
> > I'd still urge you to have a look at my zope.schema branch, which I
> > think solves a real problem with URI fields and Python 3. The patch
> > is pretty small.
>
> My zope.schema branch is largely focused on improving the unittest
> coverage, while also making the package work with Python 3.2 (i.e., not
> relying on 3.3's restoration of unicode literals).
>
> I would be glad to look at your branch; I had already considered making
> the "native string" fields APIs. I'm not sure that I agree that the
> ASCII / URI / Id / DottedName fields should have native string as its
> type: can you help by elaborating there?
For DottedName we're basically forced to use native strings as you can
import modules with unicode names on python 3:
>>> from 漢語 import Español
>>> print(Español)
Id is either a URI or a DottedName. So it must, like DottedName, also be
a native string.
As for URI, python 3 library functions seem to not care, so we can
choose either:
>>> from urllib.parse import urlparse
>>> urlparse('http://www.example.com/unicode')
ParseResult(scheme='http', netloc='www.example.com', path='/unicode',
params='', query='', fragment='')
>>> urlparse(b'http://www.example.com/bytes')
ParseResultBytes(scheme=b'http', netloc=b'www.example.com', path=b'/bytes',
params=b'', query=b'', fragment=b'')
But, for consistency's sake, URI, Id and DottedName should be the same.
That makes the best choice for URI a native string.
Another more practical argument is that having URI be a "native string"
made the porting of zope.configuration to python 3 much easier. There
were a few nasty bugs when trying it with URI as bytes.
I have no strong argument for ASCII.
FWIW, here's the original discussion on porting zope.schema:
https://mail.zope.org/pipermail/zope-dev/2011-October/043540.html
> (Also, looks like we should
> promote the 'INativeString' interface to an API).
+1
>
>
> Tres.
> - --
> ===
> Tres Seaver +1 540-429-0999 tsea...@palladion.com
> Palladion Software "Excellence by Design"http://palladion.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+ZcnUACgkQ+gerLs4ltQ4BWgCg0YOBWiGBJt8UIgBYG1F/sqsh
> qqoAoI6H77dS3EOOYFnOiQgEP6jddsNB
> =0Xwc
> -END PGP SIGNATURE-
>
> ___
> Zope-Dev maillist - Zope-Dev@zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-announce
> https://mail.zope.org/mailman/listinfo/zope )
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 3.3 port of zope.configuration
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote: > Also, do your branches still pass tests on 3.2.x? I'm sort of keen to > see both zope.schema and zope.configuration join the "2to3-free" camp > with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions > (yes, zope.configuration, I'm looking at you next). I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches. I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 3.3 port of zope.configuration
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/11/2012 03:57 AM, Brian Sutherland wrote:
> > Hi,
> >
> > I'd like to merge 2 branches which get zope.configuration's tests
> > running on Python 3.3. Here is an overview (with patches attached):
> >
> > zope.schema:
> >
> > *
> > svn+ssh://svn.zope.org/repos/main/zope.schema/branches/jinty-native_string
> >
> > * This branch corrects a mistake I think I made in the zope.schema
> > Python3 port. After my experience with the zope.configuration port I
> > now think that the URI field should be a "native" string rather than
> > bytes.
> >
> > Unfortunately this change is backwards incompatible for Python 3 users
> > of zope.schema. But I think the number users of zope.schema under
> > Python 3 are rather small at this point.
> >
> > * I make public NativeString and NativeStringLine classes. These are
> > equivalent to the Bytes type under Python 2 and the Text type under
> > Python 3. Please devote some bikeshedding energy to better names for
> > these classes ;)
> >
> > zope.configuration:
> >
> > *
> > svn+ssh://svn.zope.org/repos/main/zope.configuration/branches/jinty-python3
> >
> > * Adds a dependency on six
> >
> > * Drops Python 2.4 and 2.5 compatibility
> >
> > To run the tests of the zope.configuration branch you currently need
> > to use the zope.interface trunk.
> >
> > If there are no objections, I'll merge in a few weeks or so.
>
> How deep is the six dependency? For every package I've ported to date,
> it has ended up being more sensible to implement a local '_compat' module
> which had only the needed straddles (sometimes inspired by six, sometimes
> very localized).
I'm sure you can get away without it. But having functions from six
copied into huge numbers of zope.* packages made my skin crawl. As Jim
said "a huge DRY violation".
> Also, do your branches still pass tests on 3.2.x?
Yes for zope.schema
No for zope.configuration, but that can be fixed by changing u'' to
u('') in a lot of places.
> I'm sort of keen to
> see both zope.schema and zope.configuration join the "2to3-free" camp
zope.schema's already there, my branch is only fixing what I consider to
be a bug in the Python 3 port.
> with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions
> (yes, zope.configuration, I'm looking at you next).
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding broken/missing support to zope.interface?
On Wed, Apr 11, 2012 at 09:30:36AM -0700, Ross Patterson wrote: > Hanno Schlichting writes: > > > On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver wrote: > >> Persistent component registries are not a good enough reason to add such > >> coupling (I'd be in favor of splitting support for persistent registries > >> out of zope.component, too, while we're at it). > >> > >> Let's put the "broken" support into code which depends on > >> zope.interface, zope.component, and the ZODB, and invert the dependency > >> by having the new code install something into the base code which > >> provides the desired support: the only change to zope.interface should > >> be documenting the insertion point, and testing that it does the right > >> thing when a dummy is plugged into it. > > > > I looked at the possible contenders for that dependency description. > > The ZODB depends on zope.interface itself, though not on > > zope.component. > > > > zope.container is the one that has the most minimal dependencies, > > while still relying on zope.component and the ZODB. > > > > zope.site depends on zope.container, but given its scope sounds like > > the better place to me. I vaguely remember us discussing to move > > persistent registries into zope.site at some point. Since we moved > > zope.site.hooks into zope.component, zope.site doesn't have much else > > to do anymore. > > > > Apart from those two, there's a whole lot more that have far more > > dependencies or are unrelated in scope, like zope.annotation or > > zope.catalog. > > This problem isn't so much ZODB specific as it is specific to pickling. > The problem I don't know how to solve without modifying zope.interface > is that the on pickle end of things, the only hook I'm aware of is on > the unpickling side, namely overriding `find_global` as ZODB does. > But there's no way for `find_global` to know that the given global > should be an interface just from the module and name which is what > the pickle contains. We need to hook into the process at the time the > object is pickled. As far as I can see the only way to do that is > through the object's __reduce__ method. > > As such, the only options I see are to add something conditional to > `zope.interface.InterfaceClass.__reduce__` or to make > `zope.interface.InterfaceClass.__reduce__` hookable in some way. Would > the latter address the concerns people are raising here? Tres was suggesting something like that. It would address my concerns. > If so, what's > the right way to approach implement that? I think you need someone intimate with the ZODB to suggest that. One way might be something like the adapter_hooks already present in interface.py. That would at least be consistent, but there are probably many good reasons to not do it that way. That code could look something like: reduce_hooks = [] class InterfaceClass: def __reduce__(self): for hook in reduce_hooks: result = hook(self) if result is not None: return result return self.__name__ > Just monkey patching from > ZODB to zope.interface? Indeed, that is also another option. > > Ross > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding broken/missing support to zope.interface? (was: experimental.broken - Graceful handling of broken interfaces and components in the ZODB)
On Mon, Apr 09, 2012 at 08:15:16PM +, Martin Aspeli wrote: > On 9 April 2012 15:41, Brian Sutherland wrote: > > > On Sun, Apr 08, 2012 at 01:04:37PM -0700, Ross Patterson wrote: > > > experimental.broken is working well for me. It greatly aided me in > > > getting through a particularly nasty upgrade allowing me to cleanup the > > > ZCA cruft left by poorly behaved add-ons. I'd like to proceed with > > > adding the core of this to zope.interface and I need the > > > developers/maintainers to weigh in. > > > > > > The first and most fundamental matter is changing interface pickles such > > > that they can be unpickled into something that can fulfill the minimum > > > interface contract and don't break the ZCA. To that end, I'd like to > > > add the following to zope.interface.interface: > > > > > > ... > > > try: > > > from ZODB.broken import find_global > > > from ZODB.broken import IBroken > > > def find_interface(modulename, globalname, > > >Broken=IBroken, type=InterfaceClass): > > > """ > > > Find a global interface, returning a broken interface if it > > can't be found. > > > """ > > > return find_global(modulename, globalname, > > >Broken=IBroken, type=InterfaceClass) > > > except ImportError: > > > IBroken = Interface > > > def find_interface(modulename, globalname, > > >Broken=IBroken, type=InterfaceClass): > > > """ > > > Find a global interface, raising ImportError if it can't be > > found. > > > """ > > > # From pickle.Unpickler.find_class > > > __import__(module) > > > mod = sys.modules[module] > > > klass = getattr(mod, name) > > > return klass > > > ... > > > class InterfaceClass(Element, InterfaceBase, Specification): > > > ... > > > def __reduce__(self): > > > if self is IBroken: > > > return self.__name__ > > > return (find_interface, (modulename, globalname)) > > > ... > > > > -1 > > > > For a number of reasons, but mainly because you add a test dependency on > > the ZODB from zope.interface. I think that zope.interface is such a > > fundamental package and the dependency is unacceptable. > > > > It's a soft dependency only, looking at the code sample. Soft dependencies are cheating ;) Cheating is great when you are refactoring old code to try to minimize dependencies. For new code it's better to just do it right. > > There has lately been a LOT of work done reducing the dependency > > structure of zope.* packages. You need a VERY good reason to start > > reversing that. > > > It doesn't add any more (required) dependencies. It is required the moment you actually want to write a test for your code. That means it's pretty much required for development. Also, if you of the more fanatical sort that believe you should "run what you test and test what you run" then even a testing dependency is a real dependency. > This is a real issue that is breaking the sites of a lot of real users of > zope.interface in a way that is hard to debug and reverse. It is quite ridiculous that something as fundamental as zope.interface needs to have knowledge of a specific database implementation to avoid problems that are "hard to debug and reverse". > Can you think of a better way to get around it? Other than "don't get into > the situation" which isn't a valid answer as long as the ZTK ecosystem > supports persistent local components. I'm sorry, having never actually used the ZODB I have absolutely no idea on what level this could best be implemented. A question, do you need this code enabled all the time? Or is it something you only need during specific moments like upgrades? -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding broken/missing support to zope.interface? (was: experimental.broken - Graceful handling of broken interfaces and components in the ZODB)
ovided interface, and required interfaces are restored, > >> then the component registration is fully restored. > >> > >> If an object or registry in the ZODB is committed to the ZODB with > >> broken interfaces or components, the commit will succeed and it is still > >> possible to fully restore previous behavior if the missing classes and > >> interfaces are restored. Unfortunately, because interfaces are pickled > >> as globals, there's no good way to have the same pickle written on > >> commit for the interface as was in the original pickle, but it should > >> behave exactly the same. > >> > >> The intention of this package is to see if the implementation of broken > >> object handling is correct and robust enough to merge into > >> zope.interface and zope.component themselves. Is this the right > >> approach? If not why and what would be better? How might this approach > >> be improved? > >> > >> Ross > >> > >> -- > >> RSA(R) Conference 2012 > >> Save $700 by Nov 18 > >> Register now > >> http://p.sf.net/sfu/rsa-sfdev2dev1 > > > > ___ > > Zope-Dev maillist - Zope-Dev@zope.org > > https://mail.zope.org/mailman/listinfo/zope-dev > > ** No cross posts or HTML encoding! ** > > (Related lists - > > https://mail.zope.org/mailman/listinfo/zope-announce > > https://mail.zope.org/mailman/listinfo/zope ) > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: tseaver-better_unittests branch of zope.interface
On Mon, Mar 26, 2012 at 05:38:07PM -0400, Tres Seaver wrote: > In addition to minimizing "Zope-iness", providing full coverage using > small, descriptively-named unittests makes the code more maintainable. > For instance, I expect to build on top of these improved tests as the basis > for a conversion to a "subset", supporting Python 2.6, 2.7, and 3.x from > a single codebase, without needing a translator like lib2to3. > > I think it will also be easier to improve the docs, now that they no > longer bear the burden of supplying coverage / regression testing for > the code. We can remove a bunch of extremely-terse fragments, and have > the examples which remain focus more on improving the reader's > understanding than exercising some corner case. > > Unless the consensus is against it, I plan to merge this branch to the > trunk early next week. This sounds great, I think it's exactly the right way to go. It's just a LOT of work, a BIG thanks for taking it on! -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New release for zope.schema
On Thu, Mar 22, 2012 at 03:27:20PM +0100, Jan-Carel Brand wrote: > > (Pdb) vocabulary.__provides__.__iro__ > > (, > > ) > > > There it *does* provide IContextSourceBinder. > > Any ideas why this vocabulary doesn't provide it in Python 3? A variant of this one, perhaps: https://bugs.launchpad.net/zope.interface/+bug/911851 -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.server still used?
On Tue, Dec 20, 2011 at 08:08:36AM +0100, Wolfgang Schnerring wrote: > * Chris McDonough [2011-12-18 03:57]: > > Is zope.server still largely used by e.g. bluebream, grok, and other > > zope 3 apps? Or do people tend to use other WSGI servers instead? > > We're using zope.server on several Zope 3 projects (that were begun > before grok or WSGI or anythin existed ;), and it's *ahem* serving us > just fine, no hiccups, no nothing, just doing its job. > > (We, too, see the occasional "broken pipe" error in our logs like Marius > mentioned, I think that's due to requests that were aborted client-side, > thus more an annoyance than anything.) > > On the other hand, we still haven't found a WSGI server we're happy with > for deployment (as opposed to development). Paster has been known to > randomly die on us (yup, I've only got anecdotes and nothing hard and > fast, sorry), and the whole area of daemon management, logging, > logrotation and so forth (not to mention buildout integration) seems not > as advanced as we've come to know. What do people use here, what are > your experiences and ideas? We've been using mod_wsgi for many moons. It's certainly very stable with piles of features for managing applications. Right now we're thinking about moving to Twisted because some bits of the application are asynchronous and already written on Twisted. It simplifies things to only have one daemon running everything. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy release
On Mon, Dec 05, 2011 at 04:21:51PM -0500, Chris McDonough wrote: > Tomorrow, I plan to: > > - Merge the chrism-py3 branch of zope.sqlalchemy into its trunk. > (http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/) > to get Python 3 compatibility. > > - Once the compat branch is merged, I'll make a 0.7 release of > zope.sqlalchemy. > > Any dissent? None from me! This all looks like great work. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 1, OK: 45, UNKNOWN: 1
On Tue, Nov 15, 2011 at 01:00:03AM +, Zope tests summarizer wrote: > Non-OK results > -- > > [1]UNKNOWN UNKNOWN : Zope-trunk Python-2.6.6 : Linux >https://mail.zope.org/pipermail/zope-tests/2011-November/052670.html Looks like a network failure > [2]FAILED winbot / z3c.form_py_265_32 >https://mail.zope.org/pipermail/zope-tests/2011-November/052649.html Today's run of this buildbot is green. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 8, OK: 39
On Sun, Nov 13, 2011 at 08:22:38AM -0500, Tres Seaver wrote: > > [8]FAILED winbot / z3c.form_py_265_32 > > https://mail.zope.org/pipermail/zope-tests/2011-November/052551.html > > Stephan said yesterday he thought this was a chameleon bug. I just > tried to reproduce this on a Linux box with a fresh checkout, using > Python 2.5.5. The tests don't even run for me:: > > > Traceback (most recent call last): > > File "/tmp/zft/bin/test", line 26, in > > '--test-path', '/tmp/zft/src', > > File > > "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", > > line 30, in run > > failed = run_internal(defaults, args, script_parts=script_parts) > > File > > "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", > > line 41, in run_internal > > from zope.testrunner.runner import Runner > > File > > "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/runner.py", > > line 46, in > > import zope.testrunner.tb_format > > File > > "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/tb_format.py", > > line 19, in > > import zope.exceptions.exceptionformatter > > File > > "/tmp/zft/eggs/zope.exceptions-3.6.1-py2.5.egg/zope/exceptions/__init__.py", > > line 24, in > > import zope.security > > File > > "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/__init__.py", > > line 17, in > > from zope.security.management import checkPermission > > File > > "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/management.py", > > line 20, in > > from zope.security import interfaces > > File > > "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/interfaces.py", > > line 19, in > > from zope.schema import Text, TextLine > > File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/__init__.py", > > line 16, in > > from zope.schema._field import Field, Container, Iterable, Orderable > > File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/_field.py", > > line 78 > > class SourceText(Text): > > ^ > > SyntaxError: invalid syntax I managed to reproduce it with Python 2.6. It turned out to be a bug I introduced with the zope.schema 4.0.0 Python 3 support. I've fixed it in 123340 and released as 4.0.1. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.schema and Python 3
On Mon, Nov 07, 2011 at 01:38:21PM -0500, Jim Fulton wrote: > On Mon, Nov 7, 2011 at 1:09 PM, Brian Sutherland > wrote: > > On Fri, Oct 14, 2011 at 12:52:00PM +0200, Brian Sutherland wrote: > >> On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: > >> > I've managed to port zope.schema to Python 3.2 on a branch > >> > (jinty-python3). > >> > > >> > It gives up Python 2.5 compatibility and depends on six > >> > (http://packages.python.org/six/). Any objections to me merging this > >> > branch? > >> > >> I just merged this to trunk. > > > > Thanks to some great work by Tres, it looks like the buildbots are green > > and this change is bedded down. > > > > Could someone release zope.schema trunk? > > > > (or give me rights to do so, jinty on pypi) > > I empowered you! > > :) Drat, I forgot the unreleased Python 3 support in zope.testing. Could you empower me there too? -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.schema and Python 3
On Fri, Oct 14, 2011 at 12:52:00PM +0200, Brian Sutherland wrote: > On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: > > I've managed to port zope.schema to Python 3.2 on a branch > > (jinty-python3). > > > > It gives up Python 2.5 compatibility and depends on six > > (http://packages.python.org/six/). Any objections to me merging this > > branch? > > I just merged this to trunk. Thanks to some great work by Tres, it looks like the buildbots are green and this change is bedded down. Could someone release zope.schema trunk? (or give me rights to do so, jinty on pypi) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 21, OK: 31
On Thu, Oct 20, 2011 at 11:58:09AM -0400, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > [1]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051353.html > > > > > > > > [2]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051351.html > > > > > > > > [3]FAILED ZTK 1.0dev / Python2.6.5 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051352.html > > These > > > are all failing due to a missing version pin for 'six', which > should not happen: the ZTK 1.0 package set should not include the new > version of 'zope.schema' which introduced this dependency. > > > > [4]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051398.html > > > > > > > > [5]FAILED ZTK 1.1 / Python2.6.5 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051397.html > > > > > > > > [6]FAILED ZTK 1.1 / Python2.7.2 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051396.html > > This > > > failure is due to the unexpected presence of a 'Data.fs' file in > what is supposed to be a newly-created tempdir. I don't understand > how that is supposed to work, but the bug seems real. > > > > [7]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051354.html > > Syntax > > > errors due to Py3k compatibility changes in 'zope.schema'. The > "ZTK 1.1dev" checkouts pull in the trunk of 'zope.schema', which is > now backward-incompatible (it drops support for Python 2.5). I think > we should be creating a '3.8' branch of 'zope.schema' (copied from > 3.8.1), and make the "ZTK 1.1dev" checkout use that. Thanks for fixing these. I didn't realize that the buildouts would break because of my change. I should have though. (I've also given up looking at the buildout perma-failures a long time ago) > Meanwhile, I > think we should update the 'zope.schema' trunk to indicate that it is > targeting a new major version, 4.0, due to new dependencies and > dropping Python 2.5 compatibility. I've done this. > > [8]FAILED ZTK 1.1dev / Python2.6.5 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051356.html > > There > > > is an odd 'zope.testrunner' failure here: > > Usage: test [options] [MODULE] [TEST] > > test: error: option --profile: invalid choice: 'cProfile' (choose from ) > > > Failure in test > /home/ccomb/ztk1.1dev-slave/Python2.6.5-Linux-64bit/build/src/zope.testrunner/src/zope/testrunner/testrunner-subunit.txt > Failed doctest test for testrunner-subunit.txt > > And also the "unexpected Data.fs" issue which affected #4, 5, and 6. > > > > [9]FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit > > https://mail.zope.org/pipermail/zope-tests/2011-October/051355.html > > This > > > is the "unexpected Data.fs" issue which affected #4, 5, and 6. > > > I'm ignoring the 'z3c.*' failures: I still want these tests either > fixed or else dropped from the daily report. > > > > [21] FAILED winbot / ztk_dev py_254_win32 > > https://mail.zope.org/pipermail/zope-tests/2011-October/051382.html > > This > > > is the same Python 2.5 incompatibility problem which afflicts #7. This is a tricky issue, there are 2 parts: * Supporting python 2.5 in zope.schema is not hard, but will make the code quite ugly (no class decorator for implements) * I'm not sure if the next version of the ZTK will need to support Python 2.5 So there seem to be 3 options to fix this buildout issue: 1. Point the ZTK trunk at the zope.schema 3.8 branch 2. Make the zope.schema code uglier and support 2.5 3. Declare that the next ZTK version drops support for 2.5 and stop the buildbot for Python 2.5 + ZTK trunk I'm partial to option 1 to get the buildbot working and defer the Python 2.5/ugly code decision to later. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.schema and Python 3
On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: > I've managed to port zope.schema to Python 3.2 on a branch > (jinty-python3). > > It gives up Python 2.5 compatibility and depends on six > (http://packages.python.org/six/). Any objections to me merging this > branch? I just merged this to trunk. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.schema and Python 3
On Tue, Oct 11, 2011 at 10:43:02AM +0200, Lennart Regebro wrote: > On Tue, Oct 11, 2011 at 10:22, Brian Sutherland > wrote: > > On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: > >> I've managed to port zope.schema to Python 3.2 on a branch > >> (jinty-python3). > > > > One doubt which has just crept up on me is if these classes: > > > > ASCII, ASCIILine, URI, Id, DottedName > > > > should still inherit from Bytes on Python 3. It seems more logical that > > they should inherit from Text. I had to do some gymnastics to keep them > > bytes on python 3 and feel all dirty about it. > > > > DottedName, in particular, describes itself as "Python-style dotted > > names". But in Python 3 this code works: > > > > >>> from 漢語 import Español > > >>> print(Español) > > > > > > so a DottedName could be '漢語.Español' under Python 3. Definitely > > unicode and not Bytes. > > > > However, changing the behaviour of these classes between Python 2 and 3 > > may be even more problematic. > > > > Another option is simply to have these classes raise NotImplementedError > > in their validate() methods under Python 3 and wait till the solution > > becomes more obvious. > > > > Anyone out there willing to assuage my doubts? > > It seems to me that they should be `str`, all of them, except possibly > URI. Yeah, seems like it. I made this change to all except URI. > I'm unsure exactly how that changes the behavior. ASCII/ASCIILine > should have validators to restrict them to ASCII only, reasonably, I > don't know if they already do. It has this: if not max(map(ord, value)) < 128: raise InvalidValue which seems like it's enough. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.schema and Python 3
On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: > I've managed to port zope.schema to Python 3.2 on a branch > (jinty-python3). One doubt which has just crept up on me is if these classes: ASCII, ASCIILine, URI, Id, DottedName should still inherit from Bytes on Python 3. It seems more logical that they should inherit from Text. I had to do some gymnastics to keep them bytes on python 3 and feel all dirty about it. DottedName, in particular, describes itself as "Python-style dotted names". But in Python 3 this code works: >>> from 漢語 import Español >>> print(Español) so a DottedName could be '漢語.Español' under Python 3. Definitely unicode and not Bytes. However, changing the behaviour of these classes between Python 2 and 3 may be even more problematic. Another option is simply to have these classes raise NotImplementedError in their validate() methods under Python 3 and wait till the solution becomes more obvious. Anyone out there willing to assuage my doubts? -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.schema and Python 3
I've managed to port zope.schema to Python 3.2 on a branch (jinty-python3). It gives up Python 2.5 compatibility and depends on six (http://packages.python.org/six/). Any objections to me merging this branch? -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Referring to same interface using zope.schema.Object
On Fri, Jul 22, 2011 at 01:41:32PM +0200, Jacob Holm wrote: > On 2011-07-22 13:26, Brian Sutherland wrote: > > This would be my first guess: > > > > And that guess would be wrong. Thanks. Guess I should stop guessing;) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Referring to same interface using zope.schema.Object
On Fri, Jul 22, 2011 at 04:29:32PM +0530, Joe Steeve wrote:
> Hello,
>
> I am trying to construct an object tree. Every node in the tree is of
> the same type. I am trying to achieve something like:
>
> class INode(Interface):
>
> parent = Object(
> title=u"Parent node",
> schema=INode
> )
>
> children = List(
> title=u'Child nodes',
> value_type=Object(schema=INode)
> )
>
> The above fails with "NameError: name 'INode' is not defined". Any clues
> as to how to solve this?
This would be my first guess:
class INode(Interface):
pass
INode.parent = Object(
title=u"Parent node",
schema=INode
)
INode.children = List(
title=u'Child nodes',
value_type=Object(schema=INode)
)
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form missing *.mo files?
On Tue, Jul 12, 2011 at 07:26:59PM +0300, Marius Gedminas wrote: > On Tue, Jul 12, 2011 at 07:19:07PM +0300, Marius Gedminas wrote: > > And then what? Surely just having python-gettext installed and a couple > > of environment variables defined is not enough to magically produce .mo > > files Yes, actually it does ;) But the compiling happens during run-time when you start up the server. Neither the sdist nor binary egg need to contain the .mo files. I can't remember if it actually writes those files out to the filesystem. > -- I would also need to run some Python script somewhere, > > presumably. Is it z3c.form's bin/pocompile? > > So I tried > > cd ~/src/z3c.form > bin/pocompile > python setup.py sdist > > and found that my dist/z3c.form-2.4.5dev.tar.gz now contains a .mo next > to each .po in src/z3c/form/locales/. > > So, should I release z3c.form 2.4.5 with the .mo's? > > I would also like to add a RELEASING.txt with something like this > > If you're making a public z3c.form release to the Python Package > Index, don't forget to generate .mo files with:: > > bin/pocompile > > before you do the usual ``python setup.py sdist register upload`` > step. > > Ideally, I'd like ``python setup.py sdist`` itself to check for up-to-date > .mo's and either regenerate them automatically, or at least complain > loudly. I normally use a setuptools plugin I wrote for this: http://pypi.python.org/pypi/van.potomo The chicken and egg issue means it's probably worse than what you wrote. /me hoping that distutils2 will take care of these things. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 14, OK: 74, UNKNOWN: 3
On Thu, Apr 21, 2011 at 01:00:20AM -0400, Zope tests summarizer wrote: > [13] FAILED winbot / ztk_dev py_254_win32 >https://mail.zope.org/pipermail/zope-tests/2011-April/038623.html > > > [14] FAILED winbot / ztk_dev py_265_win32 >https://mail.zope.org/pipermail/zope-tests/2011-April/038624.html > > > [15] FAILED winbot / ztk_dev py_265_win64 >https://mail.zope.org/pipermail/zope-tests/2011-April/038625.html > > > [16] FAILED winbot / ztk_dev py_270_win32 >https://mail.zope.org/pipermail/zope-tests/2011-April/038626.html > > > [17] FAILED winbot / ztk_dev py_270_win64 >https://mail.zope.org/pipermail/zope-tests/2011-April/038627.html These are hopefully fixed in 121453. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 74 OK, 14 Failed
On Tue, Mar 29, 2011 at 10:22:45AM -0400, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Subject: FAILED : Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win > > From: jdriessen at thehealthagency.com > > Date: Mon Mar 28 15:18:14 EDT 2011 > > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036429.html > > > > Subject: FAILED : Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 > > From: jdriessen at thehealthagency.com > > Date: Mon Mar 28 16:46:58 EDT 2011 > > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036443.html > > > > Subject: FAILED : Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 > > From: jdriessen at thehealthagency.com > > Date: Mon Mar 28 16:47:05 EDT 2011 > > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036444.html > > > > Subject: FAILED : Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 > > From: jdriessen at thehealthagency.com > > Date: Mon Mar 28 17:06:20 EDT 2011 > > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/036453.html > > These four are still dying in the bootstrap step, without any kind of > useful output. I just tried to reproduce one without success:: > > - --- %< -- > $ cd /tmp > $ svn co http://svn.zope.org/repos/main/zopetoolkit/branches/1.0 > A1.0/LICENSE.txt > A1.0/development.cfg > A1.0/zopeapp-versions.cfg > A1.0/bootstrap.py > A1.0/buildout.cfg > A1.0/COPYRIGHT.txt > A1.0/ztk.cfg > A1.0/README.txt > A1.0/zopeapp.cfg > A1.0/ztk-versions.cfg > A1.0/index.rst > U 1.0 > Checked out revision 121155. > $ cd 1.0/ > $ /opt/Python-2.6.5/bin/python bootstrap.py > Creating directory '/tmp/1.0/bin'. > Creating directory '/tmp/1.0/parts'. > Creating directory '/tmp/1.0/eggs'. > Creating directory '/tmp/1.0/develop-eggs'. > Generated script '/tmp/1.0/bin/buildout'. > - --- %< -- I also couldn't reproduce the failure. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to get the board green
On Mon, Mar 21, 2011 at 11:56:05AM -0400, Tres Seaver wrote: > Too many never-resolve failures in our buildbots makes their output just > noise: the amount of effort required to diagnose the cause of a failure > seems to have no payoff if we don't get them each cleared up. +100 to any method of reducing that noise. Continuously failing buildbots shouldn't make the system unusable. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Wed, Mar 16, 2011 at 12:08:12AM +0100, Jan-Jaap Driessen wrote: > On 10 March 2011 18:18, Brian Sutherland wrote: > > On Thu, Mar 10, 2011 at 07:07:24PM +0200, Marius Gedminas wrote: > >> On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote: > >> > I now believe I've taken care of all the issues raised in your review. > >> > connection.py still feels uncomfortable, but I can live with it > >> > > >> > Unless there are any objections, I plan to merge all three branches > >> > (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week. > >> > > >> > Is there anyone willing to make releases of these to PyPI? (or give me > >> > the access to do it myself) > >> > >> I can give you PyPI access to all three. > > > > Great! > > > >> Note: when asking for PyPI access it's customary to mention one's PyPI > >> username. > > > > I hadn't used it for such a long time I even had to look it up: jinty > > > > -- > > Brian Sutherland > > ___ > > Zope-Dev maillist - Zope-Dev@zope.org > > https://mail.zope.org/mailman/listinfo/zope-dev > > ** No cross posts or HTML encoding! ** > > (Related lists - > > https://mail.zope.org/mailman/listinfo/zope-announce > > https://mail.zope.org/mailman/listinfo/zope ) > > > > Just released zope.app.wsgi 3.13 that picks up the changes in > zope.testbrowser 4.0, also updated ZTK trunk. Great, it looks like we're done. Aside from keeping an eye on the buildbots, of course. Thanks for all the help! -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Thu, Mar 10, 2011 at 07:07:24PM +0200, Marius Gedminas wrote: > On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote: > > I now believe I've taken care of all the issues raised in your review. > > connection.py still feels uncomfortable, but I can live with it > > > > Unless there are any objections, I plan to merge all three branches > > (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week. > > > > Is there anyone willing to make releases of these to PyPI? (or give me > > the access to do it myself) > > I can give you PyPI access to all three. Great! > Note: when asking for PyPI access it's customary to mention one's PyPI > username. I hadn't used it for such a long time I even had to look it up: jinty -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week. Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself) On Wed, Mar 02, 2011 at 09:16:14AM +0100, Wolfgang Schnerring wrote: > Hello Brian, > > it's taken a while, but I finally had a chance to review your branch(es). > > * Brian Sutherland [2011-02-12 18:57]: > >> > On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: > >> >> I'd prefer if we treated this as two separate steps, then: > >> >> a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with > >> >> WebTest > > > > I pulled this out of my original branch and put it here: > > > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal > > Thanks, that helped me understand what's going on much better. > > I do have a few questions about this part: > > - Does the (webtest-based) wsgi.Browser behave similarly to the > Publisher-Browser? > > When we ported the wsgi_intercept variant from zope.app.wsgi, we found > that there were some idiosyncracies woven in that people may rely on. > This kind of stuff of course isn't documented, and we didn't do much > research, but rather took care to port what we found in zope.app.wsgi, > namely filtering some HTTP headers from the response (meh, doesn't feel > important), and handling Basic Auth headers (that feels important to > preserve). > > - What should happen in zope.app.wsgi? > > We moved the wsgi-based Testbrowser from there and left BBB imports to > zope.testbrowser.wsgi, taking care to be API compatible. I guess that > won't be possible with the WebTest-based Testbrowser (or would it?), > so we probably have to break that. (Hmm, would that imply a major version > bump there, too?) > > Since the Grok people are the ones who probably use the zope.app.wsgi > Testbrowser the most, they should probably take the WebTest-Testbrowser > for a test drive and see whether it works for them, otherwise we're > going to make them quite unhappy if we just break zope.app.wsgi. > (Could you ask on grok-dev about that? I guess it's too buried here to > be noticed.) > > - What's connection.py? > > I don't really understand where that came from or what its purpose is, > especially since wsgi.py seems to be the only one that uses it? > > Ah. I take that last bit back, the extracted Publisher-Browser in > zope.app.testing uses it, so I guess this is a split-off artifact of the > refactoring/extraction. > > But I still don't really understand what it is all about. %-) > > - The layer looks good. (OK, so that's not a question ;) > > I'm glad you found a way that the browser can get the application "out > of the air". I've tried the explicit passing way on a project of mine, > and it's a huge hassle (I've ended up stuffing a preconfigured browser > instance into the doctest globs, ugh.) > > I think it would be good if the layer stored the application of > self.app, we did that in the wsgi_intercept variant and were glad of it > a few times already. > > >> >> b) extract the testbrowser part that talks to the Publisher > > > > This is here and by necessity includes the changes for step (a): > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 > > > > svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser > > The extraction of the Publisher-Browser makes a lot of sense, and looks > clean to me, as does the rewrite of the tests to use a plain WSGI app > instead of a Zope-based app. > > > I would much prefer to merge both steps together. > > Yes, I guess that makes sense because only step (b) includes proper > tests for everything. > > Wolfgang > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Sat, Mar 05, 2011 at 01:07:58AM +0100, Jan-Jaap Driessen wrote: > To get the groktoolkit tests and my company's applications to run with > Brian's zope.testbrowser+webtest branch I did the following things: > > * I created a branch of zope.app.wsgi trunk [1] to which I copied the > AuthorizationMiddleware from zope.testbrowser trunk (moved there in > [2]). The three middleware components (Transaction, Authorization and > HandleErrors) are needed to make the groktoolkit tests pass. The > AuthorizationMiddleware is not available on Brian's branch, but is > available on zope.testbrowser trunk. If we can land this middleware in > zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer. > In my opinion, this middleware should be part of zope.testbrowser, > because handleErrors is part of the IBrowser interface. > > * The `http caller` in zope.app.wsgi.testlayer is used in > grokcore.rest. On my branch, I rewrote the http caller to use WebTest > and _APP_UNDER_TEST instead of wsgi_intercept. The import from > zope.testbrowser is bothering me; can we put the http caller in > zope.testbrowser? The http caller returns a FakeResponse instance, > which could very well be a WebTest TestResponse. The FakeResponse > wrapper is merely used to fix the current tests. > > * I fixed some tests in grok and grokcore.rest to use the > WebTest-style http caller. I was pretty sure you wouldn't mind so I committed a few cleanups and bugfixes to your zope.app.wsgi branch. The trunk ztk and zopeapp tests now also pass with the three branches. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Sat, Mar 05, 2011 at 01:07:58AM +0100, Jan-Jaap Driessen wrote: > Hello from the grok department, > > On 4 March 2011 11:48, Brian Sutherland wrote: > > On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote: > >> > >> Hello, > >> > >> On Fri, 4 Mar 2011 10:15:18 +0100 > >> Brian Sutherland wrote: > >> > >> > > In zope.app.wsgi all those idiosyncracies are more or less > >> > > handled by a WSGI middleware. I guess you can reuse it. > >> > > > >> > > One of the purpose of the zope.app.wsgi implementation was to be > >> > > able to convert the existing tests just by changing the import, and > >> > > get ride of zope.testbrowser dependencies on the crazy > >> > > zope.app.testing nobody-knows-what-it-does-and-does-everything in > >> > > Grok (without adding many others). Which worked perfectly. > >> > > >> > I'll definitely look into reusing the middleware. > >> > > >> > But, tell me, how do I run all the grok tests? (So I can see what > >> > idiosyncracies are required) > >> > > >> > >> There is a Grok ToolKit, that works exactly like the Zope ToolKit: > >> > >> http://svn.zope.org/groktoolkit/trunk > >> > >> If you run this buildout you should get a ./bin/test-grok command > >> that runs all the tests, using z3c.recipe.compattest. > >> > >> Actually, I think you can start by testing only grokcore.view. I > >> guess it is one of the base packages that uses a lot the test browser. > > > > Ok, there are 2 grokcore.view failures with my branch. > > > > The first is due to the Basic Auth header and is fixable by adding the > > middleware we were talking about. > > To get the groktoolkit tests and my company's applications to run with > Brian's zope.testbrowser+webtest branch I did the following things: Great, thanks a lot!!! > * I created a branch of zope.app.wsgi trunk [1] to which I copied the > AuthorizationMiddleware from zope.testbrowser trunk (moved there in > [2]). The three middleware components (Transaction, Authorization and > HandleErrors) are needed to make the groktoolkit tests pass. The > AuthorizationMiddleware is not available on Brian's branch I've added the AuthorizationMiddleware to zope.testbrowser.wsgi and added some tests for it. It doesn't look like it'll be much of a maintenance headache being very simple with no dependencies. > , but is > available on zope.testbrowser trunk. If we can land this middleware in > zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer. > In my opinion, this middleware should be part of zope.testbrowser, > because handleErrors is part of the IBrowser interface. Hmm, the TransactionMiddleware looks very app-specific, as does the HandleErrorsMiddleware. In fact, I think you'll find that with my branch the HandleErrorsMiddleware is a no-op and can be removed. The 'wsgi.handleErrors' environment variable is set in zope.testbrowser.wsgi directly now. > * The `http caller` in zope.app.wsgi.testlayer is used in > grokcore.rest. On my branch, I rewrote the http caller to use WebTest > and _APP_UNDER_TEST instead of wsgi_intercept. The import from > zope.testbrowser is bothering me; can we put the http caller in > zope.testbrowser? The http caller returns a FakeResponse instance, > which could very well be a WebTest TestResponse. The FakeResponse > wrapper is merely used to fix the current tests. I see. I think the layer just needs to become better about exposing the global application under test. I've just committed a patch to make the .app property a get_app classmethod. So you can do: global_app_under_test = zope.testbrowser.wsgi.Layer.get_app() rather than access _APP_UNDER_TEST directly. I'd rather not move the http caller to zope.testbrowser as I'm not sure what functionality it provides over just using webtest.TestApp directly. > * I fixed some tests in grok and grokcore.rest to use the > WebTest-style http caller. > > > The other is more interesting, in > > src/grokcore/view/ftests/url/redirect.py. It seems that that test is > > actually making calls over the network to google's servers. Probably not > > a good thing. > > > > The new behaviour (probably not good either) is to send the request to > > the application even if the hostname is "www.google.com". > > > > I would guess that the right behaviour would be to raise an error if the > > hostname is not "localhost" or 127.0.0.1. > > +1 O
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote: > > Hello, > > On Fri, 4 Mar 2011 10:15:18 +0100 > Brian Sutherland wrote: > > > > In zope.app.wsgi all those idiosyncracies are more or less > > > handled by a WSGI middleware. I guess you can reuse it. > > > > > > One of the purpose of the zope.app.wsgi implementation was to be > > > able to convert the existing tests just by changing the import, and > > > get ride of zope.testbrowser dependencies on the crazy > > > zope.app.testing nobody-knows-what-it-does-and-does-everything in > > > Grok (without adding many others). Which worked perfectly. > > > > I'll definitely look into reusing the middleware. > > > > But, tell me, how do I run all the grok tests? (So I can see what > > idiosyncracies are required) > > > > There is a Grok ToolKit, that works exactly like the Zope ToolKit: > > http://svn.zope.org/groktoolkit/trunk > > If you run this buildout you should get a ./bin/test-grok command > that runs all the tests, using z3c.recipe.compattest. > > Actually, I think you can start by testing only grokcore.view. I > guess it is one of the base packages that uses a lot the test browser. Ok, there are 2 grokcore.view failures with my branch. The first is due to the Basic Auth header and is fixable by adding the middleware we were talking about. The other is more interesting, in src/grokcore/view/ftests/url/redirect.py. It seems that that test is actually making calls over the network to google's servers. Probably not a good thing. The new behaviour (probably not good either) is to send the request to the application even if the hostname is "www.google.com". I would guess that the right behaviour would be to raise an error if the hostname is not "localhost" or 127.0.0.1. > > Regards, > > Sylvain, > > -- > Sylvain Viollon -- Infrae > t +31 10 243 7051 -- http://infrae.com > Hoevestraat 10 3033GC Rotterdam -- The Netherlands -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Thu, Mar 03, 2011 at 11:04:12AM +0100, Sylvain Viollon wrote: > On Wed, 02 Mar 2011 09:16:14 +0100 > Wolfgang Schnerring wrote: > > > Hello Brian, > > > > Hello, > > > it's taken a while, but I finally had a chance to review your > > branch(es). > > > > * Brian Sutherland [2011-02-12 18:57]: > > >> > On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring > > >> > wrote: > > >> >> I'd prefer if we treated this as two separate steps, then: > > >> >> a) improve the testbrwoser+wsgi story by replacing > > >> >> wsgi_intercept with WebTest > > > > > > I pulled this out of my original branch and put it here: > > > > > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal > > > > Thanks, that helped me understand what's going on much better. > > > > I do have a few questions about this part: > > > > - Does the (webtest-based) wsgi.Browser behave similarly to the > > Publisher-Browser? > > > > When we ported the wsgi_intercept variant from zope.app.wsgi, we found > > that there were some idiosyncracies woven in that people may rely on. > > This kind of stuff of course isn't documented, and we didn't do much > > research, but rather took care to port what we found in zope.app.wsgi, > > namely filtering some HTTP headers from the response (meh, doesn't > > feel important), and handling Basic Auth headers (that feels > > important to preserve). > > > > > > Don't forget the support to do handleErrors = False. It is I think > one of the most important, which help to debug the tests. That's supported for both zope.app.wsgi and Paste applications. YMMV for other WSGI applications. > In zope.app.wsgi all those idiosyncracies are more or less handled by > a WSGI middleware. I guess you can reuse it. > > One of the purpose of the zope.app.wsgi implementation was to be able > to convert the existing tests just by changing the import, and get > ride of zope.testbrowser dependencies on the crazy zope.app.testing > nobody-knows-what-it-does-and-does-everything in Grok (without adding > many others). Which worked perfectly. I'll definitely look into reusing the middleware. But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required) > Regards, > > Sylvain, > > -- > Sylvain Viollon -- Infrae > t +31 10 243 7051 -- http://infrae.com > Hoevestraat 10 3033GC Rotterdam -- The Netherlands > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Wed, Mar 02, 2011 at 09:16:14AM +0100, Wolfgang Schnerring wrote: > Hello Brian, > > it's taken a while, but I finally had a chance to review your branch(es). Great! > * Brian Sutherland [2011-02-12 18:57]: > >> > On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: > >> >> I'd prefer if we treated this as two separate steps, then: > >> >> a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with > >> >> WebTest > > > > I pulled this out of my original branch and put it here: > > > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal > > Thanks, that helped me understand what's going on much better. > > I do have a few questions about this part: > > - Does the (webtest-based) wsgi.Browser behave similarly to the > Publisher-Browser? > > When we ported the wsgi_intercept variant from zope.app.wsgi, we found > that there were some idiosyncracies woven in that people may rely on. > This kind of stuff of course isn't documented, and we didn't do much > research, but rather took care to port what we found in zope.app.wsgi, > namely filtering some HTTP headers from the response (meh, doesn't feel > important), and handling Basic Auth headers (that feels important to > preserve). I feel strongly that these idiosyncrasies shouldn't get built into the new WSGI testbrowser and perpetuated. You had some WSGI middleware which implemented these. I think we can do it in the same way and anyone migrating from Publisher-Browser based code could use it. Perhaps that needs to be inside zope.testbrowser itself, or could be done in zope.app.wsgi. Depends on the details I guess. Unfortunately, as you say, they are undocumented and seem to be untested. I would like to make a deeper investigation of those issues and write some tests. Is there any test suite (grok perhaps?) that I can run using the new WSGI based browser that'll highlight these issues? > - What should happen in zope.app.wsgi? > > We moved the wsgi-based Testbrowser from there and left BBB imports to > zope.testbrowser.wsgi, taking care to be API compatible. I guess that > won't be possible with the WebTest-based Testbrowser (or would it?), > so we probably have to break that. (Hmm, would that imply a major version > bump there, too?) > > Since the Grok people are the ones who probably use the zope.app.wsgi > Testbrowser the most, they should probably take the WebTest-Testbrowser > for a test drive and see whether it works for them, otherwise we're > going to make them quite unhappy if we just break zope.app.wsgi. > (Could you ask on grok-dev about that? I guess it's too buried here to > be noticed.) I'll try to co-ordinate with the grok/zope.app.wsgi developers on this. I was unaware that they had BBB imports from zope.testbrowser. > - What's connection.py? > > I don't really understand where that came from or what its purpose is, > especially since wsgi.py seems to be the only one that uses it? > > Ah. I take that last bit back, the extracted Publisher-Browser in > zope.app.testing uses it, so I guess this is a split-off artifact of the > refactoring/extraction. > > But I still don't really understand what it is all about. %-) It's about minimizing the duplicated code in zope.app.testing.testbrowser and zope.testbrowser.wsgi. It's kind of "reusable pieces to build zope.testbrowser connections". That said, I'm uncomfortable with it. connection.py is probably not really very reusable. And anyone changing it would have to be aware that it was reused in zope.app.testing. Another way would be to fold connection.py into zope.testbrowser.wsgi and copy the necessary code to zope.app.testing. It's not obvious to me which way is better. You could easily persuade me another way is better. > - The layer looks good. (OK, so that's not a question ;) > > I'm glad you found a way that the browser can get the application "out > of the air". I've tried the explicit passing way on a project of mine, > and it's a huge hassle (I've ended up stuffing a preconfigured browser > instance into the doctest globs, ugh.) yeah, in the end wsgi_intercept uses global variables. So it's the same approach. > I think it would be good if the layer stored the application of > self.app, we did that in the wsgi_intercept variant and were glad of it > a few times already. Sure, I've added that. > >> >> b) extract the testbrowser part that talks to the Publisher > > > > This is here and by necessity includes the changes for step (a): > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/j
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Sat, Feb 12, 2011 at 02:59:50PM +0100, Wolfgang Schnerring wrote: > Hi, > > sorry I'm replying this late. I've been busy, then sick, then busy > again, so I'm afraid this has got pushed low on my stack of stuff... No worries, I'm not in a big rush :) > * Brian Sutherland [2011-02-02 11:15]: > > On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: > >> * Brian Sutherland [2011-01-31 09:54]: > >> I'd prefer if we treated this as two separate steps, then: > >> a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with > >> WebTest I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal The test coverage on this branch leaves much to be desired. > >> b) extract the testbrowser part that talks to the Publisher This is here and by necessity includes the changes for step (a): svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser I would much prefer to merge both steps together. > > Initially I did them together because it was the only way to get very > > good test coverage of the WebTest integration. If we do it this way, > > between steps a and b we'll have poor coverate. But that's not so bad as > > the code has already been well tested on my current branch. > > > >> As to (a), I'll still need to look at your code, but as I said I'm > >> all in favour of using WebTest instead of wsgi_intercept. > > > > I'll try make a branch for this in the next week or so for you to review. > > Thanks very much, I'll look throught it as soon as I find some time, > probably not next week (I'm travelling), but hopefully the week after > that, at the latest. Sure, I can wait a few weeks. But let me know if you're not going to get around to it. > >> As to (b), I saw you moved the code to zope.app.testing. I have a > >> few ideas in that area which I'll contact you off-list about. > > Sure! > > As we've discussed off-list, we now both feel that moving the > publisher-testbrowser to zope.app.testing is a good idea, since the only > applications that will want to use that testbrowser are those that use > zope.app.testing -- the more modern approach of testing publisher-based > applications is to use the code from zope.app.wsgi to create a WSGI > application and then use the WSGI-enabled testbrowser to talk to that. Great, looks like we have a consensus :) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Sprints at PyCon
On Thu, Feb 10, 2011 at 10:46:42AM -0500, Jim Fulton wrote: > - Better integration between webob and ztk. Yay! -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: > * Brian Sutherland [2011-01-31 09:54]: > > On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote: > >> I'd very much like there to be *one* way of doing WSGI with the > >> testbrowser, and at first blush I don't care whether that's WebTest or > >> wsgi_intercept or whathaveyou, as long as it fulfills its purpose. > > > > We have already committed to wsgi_intercept integration for the long > > term. It was released in zope.testbrowser 3.11 a few days ago, right? If > > we are to have only one way to do this, then wsgi_intercept must be it. > > I definitely don't see this as set in stone, *at all*. Yes, we've had a > release that uses wsgi_intercept for talking to WSGI apps. (And yes, we > didn't ask anyone for their opinion on it, and I'm sorry about that. > However, I guess the development process in the Zope community is an > entirely different issue, sigh.) Yeah, a totally different issue that I don't really wanna get involved in right now. > But I feel the important point about this regarding compatibility is not > the underlying technology, but the API, i. e. that > - zope.testbrowser.wsgi.Browser is a Testbrowser > - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to > facilitate the test setup. > > I think as long as we preserve this API (which seems sound to me, but of > course I'm biased ;-), we're free to change stuff under the hood. Ok, I think that that API is preservable. However I would like to make the layer optional by adding an wsgi_app keyword argument to Browser. So you can do: >>> browser = Browser(wsgi_app=app) where app is a WSGI application. Some people in the non-zope world are not too fond of layers, or use incompatible testrunners. We shouldn't force layers on them. > > But I'm ambivalent about only having one way to do things. I think > > having both integrations in zope.testbrowser is not such a bad thing. > > Having the test suite run over 2 different integrations is definitely > > good. > > Maybe I'm missing something, but when I think about the task at hand > from the client's perspective, then the only sentence that matters to me > is, "give me a zope.testbrowser that talks to this WSGI callable". > > Which means a) I couldn't care less how that's done internally as long > as it doesn't cause me any hassle and, more importantly b) I do *not* > want to have to think about it and/or make a choice about the underlying > mechanism. I want the library to have done that research (as we are > doing right now). And to me this task seems straightforward enough to > not warrant pluggability -- on the contrary, I feel it's so narrow in > scope it outright *forbids* it (but again, I may be missing something). Well, it appears that now we've reached some sort of consensus as to what base library to use. So yeah, having *one* way to do things is just fine. > >> I'll gladly review your branch, but I'd like to know the motivation > >> behind it. > > > > Only ~30% of the branch is the implementation of the WebTest connection. > > > > The other ~70% of the branch is a refactoring of the test suite. That's > > where the reduction in test dependencies comes from. The test fixture on > > the branch is a reasonably minimal WSGI application run via the WebTest > > connection. > > I'd prefer if we treated this as two separate steps, then: > a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest > b) extract the testbrowser part that talks to the Publisher Initially I did them together because it was the only way to get very good test coverage of the WebTest integration. If we do it this way, between steps a and b we'll have poor coverate. But that's not so bad as the code has already been well tested on my current branch. > As to (a), I'll still need to look at your code, but as I said I'm > all in favour of using WebTest instead of wsgi_intercept. I'll try make a branch for this in the next week or so for you to review. > As to (b), I saw you moved the code to zope.app.testing. I have a > few ideas in that area which I'll contact you off-list about. Sure! > Wolfgang > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote: > * Brian Sutherland [2011-01-30 16:04]: > > I've finally finished refactoring my WebTest/testbrowser branches, > > basically doing this: > > > > - Integrate with WebTest. zope.testbrowser.webtest.Browser is a new > > Browser implementation that uses webtest.TestApp to drive a WSGI > > application. This allows simple and direct testing of WSGI > > applications. > > > > - Re-write the test application as a pure WSGI application using WebOb. > > Run the existing tests using the WebTest based Browser > > > > - Move zope.app.testing based Browser into zope.app.testing (leaving > > backwards compatibility imports in-place). > > > > This is a very big change, so I would appreciate anyone who would take a > > look at these branches before I merge: > > Michael Howitz and I recently polished the integration of > zope.testbrowser and wsgi_intercept to accomplish pretty much the same > things you mentioned. (I'm aware that you two exchanged some emails > about it, but don't know any details). > > So I'm curious: What are the differences bewteen WebTest and > wsgi_intercept? Is one preferable to the other? The differences I've seen between the two libraries: * WebTest doesn't require a global setup/teardown. (no zope.testing Layer dependency) * With WebTest it's more difficult to accidentally end up sending real HTTP requests over the internet. I'm probably missing quite a few though. Another interesting datapoint is the number of downloads of each package from pypi.python.org: * http://pypi.python.org/pypi/wsgi_intercept/0.4 13000 downloads in 2 years * http://pypi.python.org/pypi/WebTest/1.2.3 18500 downloads in 2 months > I'd very much like there to be *one* way of doing WSGI with the > testbrowser, and at first blush I don't care whether that's WebTest or > wsgi_intercept or whathaveyou, as long as it fulfills its purpose. We have already committed to wsgi_intercept integration for the long term. It was released in zope.testbrowser 3.11 a few days ago, right? If we are to have only one way to do this, then wsgi_intercept must be it. But I'm ambivalent about only having one way to do things. I think having both integrations in zope.testbrowser is not such a bad thing. Having the test suite run over 2 different integrations is definitely good. > I'll gladly review your branch, but I'd like to know the motivation > behind it. Only ~30% of the branch is the implementation of the WebTest connection. The other ~70% of the branch is a refactoring of the test suite. That's where the reduction in test dependencies comes from. The test fixture on the branch is a reasonably minimal WSGI application run via the WebTest connection. Attached is a patch for my branch to run the test suite with the wsgi_intercept integration. I havn't committed it yet as it has multiple failures. A way forward may be to fix the wsgi_intercept integration so that it can run the full test suite then merge my branch without the WebTest integration. However I would prefer to merge the WebTest integration as is and fix the wsgi_intercept integration. > > Wolfgang > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland Index: tests/test_doctests.py === --- tests/test_doctests.py (revision 120009) +++ tests/test_doctests.py (working copy) @@ -17,26 +17,45 @@ import zope.testbrowser.ftests.wsgitestapp import zope.testbrowser.webtest +import zope.testbrowser.wsgi -def make_browser(*args, **kw): +def make_webtest_browser(*args, **kw): app = zope.testbrowser.ftests.wsgitestapp.WSGITestApplication() return zope.testbrowser.webtest.Browser(app, *args, **kw) + +class WsgiInterceptLayer(zope.testbrowser.wsgi.Layer): + +def make_wsgi_app(self): +return zope.testbrowser.ftests.wsgitestapp.WSGITestApplication() + + def test_suite(): flags = doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS -suite = doctest.DocFileSuite( +webtest_suite = doctest.DocFileSuite( 'README.txt', 'cookies.txt', 'wsgi.txt', 'fixed-bugs.txt', optionflags=flags, -globs=dict(Browser=make_browser), +globs=dict(Browser=make_webtest_browser), checker=zope.testbrowser.tests.helper
[Zope-dev] zope.testbrowser and WebTest (round 2)
I've finally finished refactoring my WebTest/testbrowser branches, basically doing this: - Integrate with WebTest. zope.testbrowser.webtest.Browser is a new Browser implementation that uses webtest.TestApp to drive a WSGI application. This allows simple and direct testing of WSGI applications. - Re-write the test application as a pure WSGI application using WebOb. Run the existing tests using the WebTest based Browser - Move zope.app.testing based Browser into zope.app.testing (leaving backwards compatibility imports in-place). This refactoring removes these test dependencies from zope.testbroswer: zope.app.appsetup zope.app.publication zope.app.testing >= 3.8.1 zope.browserpage zope.browserresource zope.component zope.container zope.principalregistry zope.ptresource zope.publisher zope.security zope.site zope.traversing And adds these: zope.pagetemplate WebTest zope.app.testing gains this dependency: zope.testbrowser >= 4.0.0dev This is a very big change, so I would appreciate anyone who would take a look at these branches before I merge: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser I plan to merge the branches in the next few weeks if there are no objections. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest
On Thu, Dec 16, 2010 at 12:06:36AM +0100, Hanno Schlichting wrote:
> On Wed, Dec 15, 2010 at 2:06 PM, Brian Sutherland
> wrote:
> > I've managed to get the existing tests to run against this browser with
> > two new testing dependencies:
> > WebTest
> > zope.app.wsgi
>
> zope.app.wsgi shouldn't be a dependency of zope.testbrowser. It's ok
> if it's pulled in via a specific extra_requires like a [webtest]
> extra, though. Zope2 depends on zope.testbrowser and has no dependency
> on any zope.app packages - this must continue to be the case. Required
> test dependencies count towards real dependencies here.
I understand your point, but the situation was already pretty nasty as
zope.testbrowser already depended on:
zope.app.appsetup
zope.app.publication
zope.app.testing >= 3.8
I agree that any extra dependency is not welcome, but this feature opens
up a path to radically reducing the dependencies of zope.testbrowser.
See below.
> The real fix would probably be to move the reusable code out of
> zope.app.wsgi into a zope.wsgi package, but that might be more than
> you are willing to do now. I do believe some of the Grok people would
> be interested in this as well.
There is also another route open now with the addition of the webtest
feature. We could invert the zope.testbrowser -> zope.app.testing
dependency.
This is a major re-factoring, but will leave the zope.testbrowser
dependencies looking like this:
install_requires = [
'mechanize>=0.2.0',
'setuptools',
'zope.interface',
'zope.schema',
'pytz',
],
extras_require = {
'test': [
'WebOb',
'WebTest',
]
Basically this would require:
* Re-writing the zope.testbrowser.ftests test application as a pure
WSGI app (using WebOb)
* Test only against zope.testbrowser.wsgi and refactor tests to not
use features from zope.app.testing.functional
* Move zope.testbrowser.testing into zope.testbrowser.wsgi and
zope.app.testing.testbrowser
* Leave backwards compatibility imports in place in
zope.testbrowser.testing
I'd be willing to have a look at this if Benji were OK in principle on
this and someone was willing to review it.
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest
On Wed, Dec 15, 2010 at 08:53:00AM -0500, Benji York wrote: > If you want, I should have time to review your branch again before you > merge it. Ok, I've done some minimal refactoring and am ready to merge the branch when you've reviewed it. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest
On Wed, Dec 15, 2010 at 08:53:00AM -0500, Benji York wrote: > On Wed, Dec 15, 2010 at 8:06 AM, Brian Sutherland > wrote: > > I've committed a WebTest integration with testbrowser to a > > "jinty-webtest" branch. It basically uses WebTest as a backend to drive > > a WSGI application. > > This sounds like a nice improvement over using wsgi-intercept > (http://code.google.com/p/wsgi-intercept/). Exactly. I've been using that for a while, but it finally irritated me too much... > I've taken a quick look at the branch. I saw a few of these in the > diff: > > ->>> from zope.testbrowser.testing import Browser > +XXX: what to do with this? > +XXX>>> from zope.testbrowser.testing import Browser > > If you can give me some background maybe I can help with these. I now run the tests twice but with a different Browser variable which comes from the test setup. So I need to think of a way of changing the documentation so that it is still clear. > The copyright date in src/zope/testbrowser/wsgi.py needs the current year. Sure, I'll fix that. > I suspect large chunks of zope.testbrowser.wsgi can be eliminated with > judicious refactoring. As you saw, I took the easy way out by copying testing.py. I wanted to see how easy it was to get the tests passing against WebTest. I'll correct my lazyness shortly ;) > If you want, I should have time to review your branch again before you > merge it. That'd be great. I'll do the refactoring and documentation fixed then ping you again. There's also a single remaining test failure that I may need your help with. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.testbrowser and WebTest
Hi, I've committed a WebTest integration with testbrowser to a "jinty-webtest" branch. It basically uses WebTest as a backend to drive a WSGI application. This feature makes it possible to do this in a test: >>> app = make_my_wsgi_app() >>> from webtest import TestApp >>> from zope.testbrowser.wsgi import Browser >>> browser = Browser(TestApp(app)) And then use the browser as normal. I've managed to get the existing tests to run against this browser with two new testing dependencies: WebTest zope.app.wsgi If anyone objects to this feature, or wants to review it before I merge, please let me know. I will definitely fix the documentation and remaining test failure before merging. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface memory optimization
On Wed, Nov 10, 2010 at 12:07:00PM +0100, Charlie Clark wrote: > Am 10.11.2010, 01:40 Uhr, schrieb Brian Sutherland > : > > >> > On the micro benchmarks, the only difference I see is a memory > >> > improvement which I think will not survive in practice because most > >> > >> ... ? > > Er, somehow my thoughts didn't make it into text: > > attributes are zope.schema fields (i.e. subclasses of Attribute). > > To really make that work, you'd have to add __slots__ to most of the > > classes in zope.schema as well. > > It might be purely academic but if this does significantly reduce memory > use then it might be worth pursuing. Turns out it's not that academic. I tried a bit harder and managed to apply __slots__ to the Element, Attribute and Method classes in zope.interface. That saved an additional 0.5 % of memory (bytes). I have a small patch to zope.schema that fixes the breakage there. It looks like there is an additional 0.5% available if zope.schema is refactored to use slots as well. > Slots are supposed to be beneficial > when you've got lots of objects around. Zope schema fields are pretty > static anyway so I don't see a great penalty in having to add slots to > them, although obviously a migration of a larger project would probably be > a pain. Searching for __dict__ here: http://zope3.pov.lt/trac/browser/zope.schema/trunk/src/zope/schema/_bootstrapfields.py Will give you a good idea of the problems. Field.bind and ValidatedProperty both depend heavily on __dict__. For ValidatedProperty in particular I have no idea how that would work when using slots. > Back to the micro-optimisation. At Jeff Rush's talk at PyCon this year he > covered the penalties incurred by "." lookups so that might be something > that could be investigated but might it also be possible to "memoize" the > method calls? I keep forgetting when you can't do that. I had a look at http://en.wikipedia.org/wiki/Memoization, but I don't see how it could be applied in this case. > Charlie > -- > Charlie Clark > Managing Director > Clark Consulting & Research > German Office > Helmholtzstr. 20 > Düsseldorf > D- 40215 > Tel: +49-211-600-3657 > Mobile: +49-178-782-6226 > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.interface/branches/jinty-mem/src/zope/interface/interface.py Improve CPU performance of previous memory optimization
On Tue, Nov 09, 2010 at 03:01:09PM -0500, Tres Seaver wrote:
> > I think the is a possible threading issue with Element.setTaggedValue
> > and Specification.subscribe - if two threads called the method
> > concurrently, then one of the values might be lost. I think the
> > correct way to do it would be:
> >
> > tv = self.__tagged_values
> > if tv is None:
> > tv = self.__dict__.setdefault('_Element__tagged_values', {})
> > tv[tag] = value
> >
> > This does bring the name mangling back though.
Thanks, I fixed the threading issue in Specification.subscribe. Given
that that part of subscribe is not run very often, I think we can live
with limited name mangling.
> I'm pretty sure we can safely neglect threading issues here: no sane
> code will call 'setTaggedValue' except at import time, when we should be
> serialized by Python's own import lock.
Great, I quoted you on that ;)
The setdefault fix for the threading issue is not compatible with the
use of __slots__. I couldn't find another way to do it.
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface memory optimization
On Wed, Nov 10, 2010 at 12:14:54AM +0200, Marius Gedminas wrote: > On Tue, Nov 09, 2010 at 05:04:11PM +0100, Brian Sutherland wrote: > > > Might be worth timing a slots-based implementation. > > > > I just tried to add slots to Element, Attribute and Method classes, but > > it there's too many tests that break to benchmark it running the ZTK > > tests. > > > > On the micro benchmarks, the only difference I see is a memory > > improvement which I think will not survive in practice because most > > ... ? Er, somehow my thoughts didn't make it into text: attributes are zope.schema fields (i.e. subclasses of Attribute). To really make that work, you'd have to add __slots__ to most of the classes in zope.schema as well. > > > Marius Gedminas > -- > http://pov.lt/ -- Zope 3/BlueBream consulting and development > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface memory optimization
On Tue, Nov 09, 2010 at 03:49:38PM +0100, Charlie Clark wrote:
> Am 08.11.2010, 15:35 Uhr, schrieb Brian Sutherland
> :
>
> > If no-one replies, I'll assume that 3% is just not enough to be
> > interesting and do nothing;)
>
> Hi Brian,
>
> thanks for sharing this but it looks to me like a micro-optimisation that
> isn't really worth going against best practice for - by using explicit
> name-mangling.
>
> -return self.__tagged_values.get(tag, default)
> +return getattr(self, '_Element__tagged_values', {}).get(tag,
> default)
In response to Marius' comments I changed the patch a bit earlier to
this:
def queryTaggedValue(self, tag, default=None):
""" Returns the value associated with 'tag'. """
tv = self.__tagged_values
if tv is None:
return default
return tv.get(tag, default)
Which is is faster as well as not doing the explicit name mangling you
object to.
> Any improvements higher up the stack (using slots, different Python
> version or compilers like LLVM) are likely to have a more significant
> effect.
That would be great, when it arrives.
Actually, in my case, memory is the issue. So the only optimization
that'll really help in a big way is if multiple python processes running
similar code start sharing data.
Some people have poked at that problem, but I havn't seen anything
significant yet.
> Might be worth timing a slots-based implementation.
I just tried to add slots to Element, Attribute and Method classes, but
it there's too many tests that break to benchmark it running the ZTK
tests.
On the micro benchmarks, the only difference I see is a memory
improvement which I think will not survive in practice because most
> Charlie
> --
> Charlie Clark
> Managing Director
> Clark Consulting & Research
> German Office
> Helmholtzstr. 20
> Düsseldorf
> D- 40215
> Tel: +49-211-600-3657
> Mobile: +49-178-782-6226
> ___
> Zope-Dev maillist - Zope-Dev@zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-announce
> https://mail.zope.org/mailman/listinfo/zope )
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface memory optimization
On Tue, Nov 09, 2010 at 01:21:00AM +0200, Marius Gedminas wrote:
> On Mon, Nov 08, 2010 at 03:35:09PM +0100, Brian Sutherland wrote:
> > I've committed 2 patches to a "jinty-mem" branch of zope.interface.
> > Together these patches reduce the startup memory use of my ZTK based
> > application by 3%. Is that enough to justify their risk/complexity?
> >
> > https://mail.zope.org/pipermail/checkins/2010-November/052516.html
> > https://mail.zope.org/pipermail/checkins/2010-November/052517.html
> >
> > If no-one replies, I'll assume that 3% is just not enough to be
> > interesting and do nothing;)
>
> It's so interesting I'm going to ask for even more numbers: how much is
> that 3% in kilobytes, or objects?
Ok, you asked for it ;)
The 3% was in kilobytes as measured using /bin/ps on OSX leopard with
python2.6 from MacPorts. The app I measured is a ZTK 1.0 based web
application.
My application without the changes:
Objects:245614
RSS memory (kb):59116
My application with the changes:
Objects:227147
RSS memory (kb):57180
I also did a micro-benchmark (more below) which indicate that when
creating an interface with 5 attributes and 5 methods you save 41% in
kilobytes and 34% in objects.
> Is there any measurable speed impact
> for application startup or test runs (faster/slower)?
My app doesn't startup measurably faster or slower. The ZTK tests seem
to run a little faster, but the error is high on my laptop:
Without patches:
./bin/test-ztk 71.93s
./bin/test-ztk 70.49s
./bin/test-ztk 70.31s
With patches:
./bin/test-ztk 70.28s
./bin/test-ztk 70.00s
./bin/test-ztk 69.98s
I also did some micro-benchmarking (script is attached). There were
repeatable results which indicate that startup will be faster and
runtime only probably faster:
Without patches:
Performance bench
-
one interface, 5 methods, 5 functions: 181.00 usec/pass
five inheriting interfaces: 355.76 usec/pass
one interface: 59.79 usec/pass
query uninitialized tagged value: 1.26 usec/pass
query initialized tagged value: 1.27 usec/pass
Memory bench
Memory before (kb):
RSS VSZ
33684 109780
objects created: 150001
Memory after (kb):
RSS VSZ
47856 124116
With patches:
Performance bench
-
one interface, 5 methods, 5 functions: 165.97 usec/pass
five inheriting interfaces: 341.22 usec/pass
one interface: 53.03 usec/pass
query uninitialized tagged value: 0.75 usec/pass
query initialized tagged value: 1.37 usec/pass
Memory bench
Memory before (kb):
RSS VSZ
33328 109524
objects created: 99001
Memory after (kb):
RSS VSZ
41728 117972
> Otherwise I'm +1, assuming this doesn't somehow make the code 10%
> slower.
>
> Marius Gedminas
> --
> http://pov.lt/ -- Zope 3/BlueBream consulting and development
> ___
> Zope-Dev maillist - Zope-Dev@zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-announce
> https://mail.zope.org/mailman/listinfo/zope )
--
Brian Sutherland
#
# Perdormance Benchmark
#
import os
import timeit
import subprocess
from zope.interface import Interface, Attribute
print "Performance bench"
print "-"
s1 = """\
class I1(Interface):
a1 = Attribute('one')
a2 = Attribute('two')
a3 = Attribute('thee')
a4 = Attribute('four')
a5 = Attribute('five')
def f1(arg):
pass
def f2(arg):
pass
def f3(arg):
pass
def f4(arg):
pass
def f5(arg):
pass
"""
t = timeit.Timer(stmt=s1, setup="from zope.interface import Interface,
Attribute")
print "one interface, 5 methods, 5 functions: %.2f usec/pass" % (100 *
t.timeit(number=1)/1)
s1 = """\
class I1(Interface):
pass
class I2(I1):
pass
class I3(I2):
pass
class I4(I3):
pass
class I5(I4):
pass
"""
t = timeit.Timer(stmt=s1, setup="from zope.interface import Interface,
Attribute")
print "five inheriting interfaces: %.2f usec/pass" % (100 *
t.timeit(number=1)/1)
s1 = """\
class I1(Interface):
pass
"""
t = timeit.Timer(stmt=s1, setup="from zope.interface import Interface,
Attribute")
print "one interface: %.2f usec/pass" % (100 * t.timeit(number=1)/1)
setup = ""&qu
[Zope-dev] zope.interface memory optimization
I've committed 2 patches to a "jinty-mem" branch of zope.interface. Together these patches reduce the startup memory use of my ZTK based application by 3%. Is that enough to justify their risk/complexity? https://mail.zope.org/pipermail/checkins/2010-November/052516.html https://mail.zope.org/pipermail/checkins/2010-November/052517.html If no-one replies, I'll assume that 3% is just not enough to be interesting and do nothing;) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.appsetup and RootErrorReportingUtility
On Mon, Aug 30, 2010 at 03:01:24PM +0200, Adam GROSZER wrote: > Hello, > > zope.app.appsetup installs the following RootErrorReportingUtility: > > ensureUtility(root_folder, IErrorReportingUtility, '', > RootErrorReportingUtility, copy_to_zlog=False) > > My problem with this is that copy_to_zlog=False, that means if your > app is *really* hosed you don't get the error logged to the usual > error.log or event.log and are also *unable* to access the UI of the > utility. > > Anyone objects a change to "copy_to_zlog=True" as default? +1 -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] docs.zope.org automation
On Mon, Aug 02, 2010 at 06:34:21PM +0200, Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 8/2/10 18:26 , Martijn Faassen wrote: > > http://packages.python.org/distribute/pkg_resources.html > > > > You can probably create a Distribution object somehow (handwave) from a > > path (whether that's the path of the package or the path the package is > > in, not sure). > > The issue, just like with pkginfo.Develop, is that I can't find any > function or method that finds package information in subfolders. If you > look at... > > http://packages.python.org/distribute/pkg_resources.html#getting-or-creating-distributions > > ...there's this function find_distributions which supposedly offers > subfolder searching, but it just doesn't work. At least it doesn't do > what I would expect when I read the documentation. It finds nothing. Do you have access to an source distribution (tarball or zip) for the package involved? In the source distribution the PKG-INFO file is always at the top level. > jens > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkxW840ACgkQRAx5nvEhZLK0MgCfWNsSL47dimbU9TlIZNSRq07h > HLIAoIYYLdYUsA5PhYrtqhu9EaVk8Nip > =GbbC > -END PGP SIGNATURE- > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Uses of the ZTK and how it relates to management
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote: > On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland > wrote: > > On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: > >> In the specific case of zope.event, I'd prefer it stay separate. I > >> want developers to be able to publish events without having to commit > >> to a subscription mechanism. For example, ZODB depends on zope.event > >> so it can generate events and provide a generic hook mechanism. I > >> don't want it to depend on zope.component. > > > > I just committed a jinty-optional-event branch for zope.component that's > > an experiment as to how to make the dependency on zope.event optional. > > Maybe I'm missing something, but zope.event is so minimal I can't see > that making optional is worth the effort. Actually, I misunderstood your question. Personally, I also don't think it's worth the effort. But it's come up a few times already, so is obviously something some group of people want. The effort, also, is actually quite small as can be seen on the branch. Perhaps it's even an effort saver if it prevents the topic coming up again and again ;) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Uses of the ZTK and how it relates to management
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote: > On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland > wrote: > > On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: > >> In the specific case of zope.event, I'd prefer it stay separate. I > >> want developers to be able to publish events without having to commit > >> to a subscription mechanism. For example, ZODB depends on zope.event > >> so it can generate events and provide a generic hook mechanism. I > >> don't want it to depend on zope.component. > > > > I just committed a jinty-optional-event branch for zope.component that's > > an experiment as to how to make the dependency on zope.event optional. > > Maybe I'm missing something, but zope.event is so minimal I can't see > that making optional is worth the effort. One point is backwards compatibility, the other is to allow zope.component subscribers to listen to ZODB events if the ZODB only depends on zope.event but not on zope.component. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Uses of the ZTK and how it relates to management
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: > On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting wrote: > > On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune wrote: > >> A thought that came up when reading this paragraph: another option > >> restructuring/grouping to reduce the amount of packages may be to join > >> smaller packages with weird boundaries into larger ones again. (Not that > >> I suggest this to be an ultimate option, nor do I know from the top of > >> my head any candidates for this, but we can keep that on the list of > >> options we have.) > > > > I think this is a good idea, but I wouldn't want to do it on a package > > level. Rather do it on the distribution level. Once the distutils2 > > improvements are available, we have the means to say "distribution A > > obsoletes B". > > > > As a simple example that would allow us to put zope.event into the > > zope.component distribution, without having to change any import paths > > or setup.py install_requires lines. The zope.component distribution > > would have the metadata to say "I obsolete zope.event", so if someone > > has such a version of zope.component, requirements of the zope.event > > distribution would be automatically satisfied. > > > > This same method could be taken to build more functional distribution > > out of related packages we have today. These distributions might also > > be easier to market, document and explain. But they come with the > > downside of more buy-in per distribution. Figuring out how packages > > are actually used and which ones are used independently is no small > > task. > > Your description of the mechanism sounds interesting. > > In the specific case of zope.event, I'd prefer it stay separate. I > want developers to be able to publish events without having to commit > to a subscription mechanism. For example, ZODB depends on zope.event > so it can generate events and provide a generic hook mechanism. I > don't want it to depend on zope.component. I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional. zope.event will still be used if it is around but zope.component will provide it's own implementation if not. Other packages which only depend on zope.component can break their dependency on zope.event. > Ideally, I'd like other projects to adopt zope.event, or for something > like zope.event to be included in the standard library, although, I'm > unlikely to push that politically, so it will probably never happen. > :/ > > Jim > > -- > Jim Fulton > _______ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
On Wed, Mar 03, 2010 at 12:06:22PM +0200, Marius Gedminas wrote: > Marius Gedminas > now wondering if his humorous deadpan PEP-8 review of pseudocode will be > considered positive or negative... I, for one, have always thought them positive and read them eagerly. But, then you've never reviewed one of my, admittedly few, commits;) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Evaluating a zope.i18nmessageid memory leak patch
Hi all, We've been using this patch in production for some weeks and testing for months: http://launchpadlibrarian.net/37237733/_zope_i18nmessageid_message.c.patch To resolve this bug: https://bugs.launchpad.net/zope3/+bug/257657 The patch seems to do what it claims and I've not noted any nasty side-effects thus far. However, before I commit it, I'd appreciate it if someone with knowledge of python C-extension fu had a look at it. I attempted to write a test for this, but my only idea (using weakref.ref) failed. If no-one objects, I'll probably just commit the patch anyway after some time. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adding W3C validating to zope.testbrowser
On Tue, Feb 23, 2010 at 04:57:02PM +0200, Marius Gedminas wrote: > On Tue, Feb 23, 2010 at 08:57:09AM -0500, Benji York wrote: > > On Sat, Feb 20, 2010 at 7:53 AM, Ross Patterson wrote: > > > I started a branch for doing W3C HTML validation on responses to > > > zope.testbrowser requests: > > > > > > svn://svn.zope.org/repos/main/zope.testbrowser/branches/rossp-validator > > > > > > The idea is to be able to flip a switch and run all my functional > > > zope.testbrowser tests and see validation failures as test failures. > > > > I'm not keen on this idea. Validation checking isn't hard to do with > > testbrowser as-is, and doing it on every page load is overkill. Add to > > that the global nature of the required switch and this really doesn't > > seem like the right approach. > > I'd like to chime in and suggest using WSGI to hook up zope.testbrowser > and zope.app.testing.functional (or a better-designed replacement for > the latter). Then you could plug in W3CValidatingMiddleware (if one > doesn't exist, it should be trivial to write it) between them. We use wsgi_intercept to get zope.testbrowser to listen to the other end of a WSGI pipe during testing http://pypi.python.org/pypi/wsgi_intercept The testbrowser integration we have is far from perfect but was enough for is to stop using zope.app.testing.functional http://svn.zope.org/van.testing/trunk/van/testing/layer.py?rev=105324&view=markup It would be pretty simple to have a make_application call that wrapped the application in validating middleware depending on an environment variable. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Decimal validation error.
On Wed, Feb 10, 2010 at 12:25:51PM -0800, Mats Nordgren wrote: > Seems a plain vanilla install of bluebream validates decimals fine with > zope.app.form. Does z3c.form validate decimal fields or is that delegated > to zope.schema? I also hit this, AFAIKR z3c.form delegates it to zope.i18n. We worked around this (no proper solution I'm afraid) by overriding the default DataConverter in z3c.form. > > On Wed, Feb 10, 2010 at 8:27 AM, Mats Nordgren wrote: > > > I have an interface with a decimal field. It validates fine for 1,2 and 3 > > fractions but if I enter a decimal with 4 fractions I get validation error > > "The entered value is not a valid decimal literal." > > > > I'm using the pypi release of bluebream and z3c.form 2.3.2. > > > > Mats > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Interfaces vs ZCA concepts
her renders the new methods unusable with anything > >> that's > >> not very much like zope.component, or makes for a half-hearted copy of the > >> functionality we currently have in the zope.component API. > >> > >> I discussed this a bit with Wolfgang as we both don't like this kind of > >> compromise in such core functionality. We came up with the idea that a > >> clean > >> solution would be to keep any implementation of the two methods out of > >> zope.interface and rather inject them into the interface API by code kept > >> entirely within zope.component. We do realise how close to the concept of > >> monkey-patching this comes, but maybe it wouldn't be so bad if we could do > >> it > >> in a more structured way (being intentionally vague here yet). > >> > >> In particular, keeping the concrete `adapt` and `utility` methods out of > >> the > >> core implementation of interfaces would address the concern raised by > >> somebody > >> on this list that we were going to tailor zope.interface too much to the > >> needs > >> of the Zope ecosystem. Uses of interfaces other than adaptation and > >> component > >> lookup could get convenience methods registered by the same mechanism > >> zope.component would end up employing, which is a big conceptual advantage > >> from my point of view. > >> > >> What do people think of this? > >> > >> -- > >> Thomas > >> > >> > >> > >> ___ > >> Zope-Dev maillist - Zope-Dev@zope.org > >> https://mail.zope.org/mailman/listinfo/zope-dev > >> ** No cross posts or HTML encoding! ** > >> (Related lists - > >> https://mail.zope.org/mailman/listinfo/zope-announce > >> https://mail.zope.org/mailman/listinfo/zope ) > >> > > ___ > > Zope-Dev maillist - Zope-Dev@zope.org > > https://mail.zope.org/mailman/listinfo/zope-dev > > ** No cross posts or HTML encoding! ** > > (Related lists - > > https://mail.zope.org/mailman/listinfo/zope-announce > > https://mail.zope.org/mailman/listinfo/zope ) > > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
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 context
> > provides IFoo, in which case it returns context.
> >
> > IFoo.utility() raises LookupError.
> >
> > IFoo.utility(default=default) returns default
>
> 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
> zope.interface and zope.component, but they still lie about the actual
> method signature. In that sense, these stubs would be worse than
> zope.interface not documenting the methods at all.
>
> In my and Wolfgang's opinion, we can either have zope.interface implement
> methods with the real contract, which would mean defining the full
> concepts of the ZCA within zope.interface (if not their implementation),
> or not even have method stubs in zope.interface and leave the whole
> business of defining specialised uses of interfaces to other packages such
> as zope.component.
I like things to fail noisily and loudly unconfigured and give good
information about what's wrong. So my preferred implementation of a
stub "utility" function on Interface is:
def utility(default=None):
"""Lookup a utility for this interface.
A utility is a ${long explanation of utility concept}.
This method behaves like ${explanation of utility method contract}.
"""
raise NotImplementedError("""No Utility lookup mechanism has been
configured.
If you wish to use utility lookups on interfaces, please configure a
package that contains this mechanism. Packages known to
implement this are:
zope.component
""")
I agree that this encodes in the zope.interface package concepts from
zope.component. I feel uncomfortable about that. But I feel more
uncomfortable with magic where it is impossible to find out what is
going on by reading the code.
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the ZCA API decision
On Thu, Dec 03, 2009 at 06:41:03PM +0100, Martijn Faassen wrote: > 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 will be added to Interface. It takes optional but > explicit 'default' and 'name' arguments. > > On the adapter hook (__call__) we will deprecate the implicit second > argument for defaults, with a deprecation warning. Instead, we will > require people to write out 'default=' explicitly. Otherwise its > behavior remains unchanged. I think we can motivate this change purely > because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, > default=baz). FWIW, I'm +1 as well. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the ZCA API decision
On Thu, Dec 03, 2009 at 03:11:07PM -0700, Shane Hathaway wrote: > Godefroid Chapelle wrote: > > 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. > > AFAICT, the decision to reject or postpone that has been postponed. :-) While taking steps now to soften the backwards compatibility issues for that future decision. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 10:17:41PM +0100, 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] > > > which strikes me as wildly disjoint: the IFoo behavior is "expected" > > (short-circuit the lookup if the object already provides the interface), > > while the getAdapter behavior is a puzzlement. > > This has been mentioned numerous times as one of those odd and > unexpected differences between the IFoo vs. get/queryAdapter semantic. > IIRC the only use-case I ever heard of for the getAdapter semantic, > was the possibility to override the behavior promised by the interface > with a different adapter without touching the class that implements > the interface directly. > > I think changing this falls into the category of: Small backwards > incompatibly that seem worthwhile to make the behavior consistent and > expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the "main API" to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. > > Hanno > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote: > What about a simple and consistent API for all components including > utilities, adapters and multiadapters: > > IFoo() > IFoo(x) > IFoo(x, y) This also doesn't allow you to use this (anti?)pattern: class Foo: implements(IFoo) def do_something(self): # custom behaviour here default_foo_adapter = getAdapter(self, IFoo) return default_foo_adapter.do_something() # fallback to default behaviour It may not be very theoretically correct, but it's something I find very useful when writing IPublishTraverse implementing classes for zope.publisher to traverse over. It saves me from having to inherit from the default traverser. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
On Mon, Jun 22, 2009 at 09:01:16AM -0400, Jim Fulton wrote: >>> - Create zope.publication from zope.app.publcatiobn >>> - use webtest rather than zope.app.testing. >> >> What's webtest? > > http://pythonpaste.org/webtest/ > > It's sort of like zope.app.testing.functional or zope.testbrowser but > for WSGI apps. It *just* handles the publishing aspects of testing. > Tests can then manage their own application setup. I think this will > make many tests simpler and cleaner as they can set up just enough of an > application as they need for their tests. Ah, very interesting, so far I've been using wsgi-intercept which is very similar and has been working well for me. http://code.google.com/p/wsgi-intercept/ Though webtest, re-using the WebOb request does look interesting. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: ZTK custom publications, zope.app.publication, and zope.traversing
On Sun, Jun 21, 2009 at 11:55:50AM -0400, Jim Fulton wrote: > - It aggressively proxies objects using > zope.security.checker.ProxyFactory. Some people don't want >to use proxies and those that do might want to use a different > proxy or checker implementation. Grok's publication sub-class is similar to mine: http://svn.zope.org/grok/trunk/src/grok/publication.py?view=markup We I think we both want security proxies around views, but not during traversal. I've also heard of people who want proxies around the context and view, but not during traversal. It's pretty difficult to do the above securely, or at least I was able to open massive security holes while prototyping my publication object;) Witness grok's "if IBrowserView.providedBy" dance in the URL above. > Maybe in phase 3: > > - Create zope.publication from zope.app.publcatiobn > - use webtest rather than zope.app.testing. What's webtest? > Thoughts? Sounds good! > > Jim > > -- > Jim Fulton > Zope Corporation > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Exposing a zope-testrunner binary in zope.testing
Hi,
Any objections to me adding this line to zope.testing's setup.py:
entry_points = {'console_scripts': ['zope-testrunner =
zope.testing.testrunner:run',]},
It'll create a zope-testrunner binary which we would like to use in
automatically testing zope Debian packages from the command line.
Currently the test scripts look like:
http://svn.debian.org/viewsvn/pkg-zope/zope.component/trunk/debian/tests/all?revision=1397&view=markup
Which is pretty scary...
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] uuid.UUID as a rock in zope.security
Hi,
We're using UUIDs a lot, and it's pretty painful that they are security
proxied. They're in the standard library from python 2.5
(http://docs.python.org/library/uuid.html) and are immutable according
to the documentation.
I think they meet all the all the requirements to be rocks. So unless
someone complains, I'll commit the attached patch in a few days.
--
Brian Sutherland
Index: CHANGES.txt
===
--- CHANGES.txt (revision 98805)
+++ CHANGES.txt (working copy)
@@ -5,7 +5,8 @@
3.6.4 (unreleased)
--
-- None so far.
+- Make uuid.UUID a rock, they are immutable and in the python standad library
+ from python 2.5.
3.6.3 (2009-03-23)
--
Index: src/zope/security/checker.py
===
--- src/zope/security/checker.py(revision 98805)
+++ src/zope/security/checker.py(working copy)
@@ -624,6 +624,13 @@
type(pytz.UTC): NoProxy,
})
+try:
+# NOTE: remove try/except when we depend on python2.5 and up. uuid in
standard library from python 2.5.
+from uuid import UUID
+BasicTypes[UUID] = NoProxy
+except ImportError:
+pass
+
# Available for tests. Located here so it can be kept in sync with BasicTypes.
BasicTypes_examples = {
object: object(),
Index: src/zope/security/tests/test_standard_checkers.py
===
--- src/zope/security/tests/test_standard_checkers.py (revision 98805)
+++ src/zope/security/tests/test_standard_checkers.py (working copy)
@@ -424,6 +424,14 @@
>>> from pytz import UTC
>>> int(type(ProxyFactory( UTC )) is type(UTC))
1
+
+>>> try:
+... # NOTE: remove try/except when we depend on python 2.5 and greater
(uuid in standard library)
+... from uuid import UUID
+... int(type(ProxyFactory( UUID('12345678123456781234567812345678')
)) is UUID)
+... except ImportError:
+... 1
+1
"""
def test_iter_of_sequences():
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Releasing z3c.recipe.i18n?
Hi, I've added a oneline bugfix to z3c.recipe.i18n that's pretty important for me (97979). Could someone release it? or add me as an owner in pypi so I can do it myself? My pypi username is jinty. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
On Mon, Feb 09, 2009 at 07:28:11AM -0800, Stephan Richter wrote: > On Monday 09 February 2009, Brian Sutherland wrote: > > > Oh, also, I guess it should use z3c.ptcompat rather than z3c.pt.compat > > > for z3c.pt thing. > > > > I have a branch for that, but am blocked on merging that because the > > z3c.ptcompat code has test failures (in itself and z3c.form). These test > > failures existed before I moved z3c.pt.compat to z3c.ptcompat. > > Check it in; it will save Dan some time. ;-) Merged in 96320. > > Regards, > Stephan > -- > Stephan Richter > Web Software Design, Development and Training > Google me. "Zope Stephan Richter" > -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
On Mon, Feb 09, 2009 at 10:52:01AM +0300, Dan Korostelev wrote: > 2009/2/9 Dan Korostelev : > > 2009/2/9 Stephan Richter : > >> Anyone, how close are we to a z3c.form 2.0 release? > > > > I worked on the multi widget a little some time ago, adding > > conditional add/remove buttons. However, there are still some (not too > > important though) TODOs on it. > > > > Also, there's a really strage bug with macros when using z3c.pt > > discovered in tests/simple_groupedit.pt. I leaved a comment there [1], > > I guess that's for Malthe. :-) > > > > I think, I'll try to make a review of current z3c.form's state and > > write more on that. > > > > [1] > > http://svn.zope.org/z3c.form/trunk/src/z3c/form/tests/simple_groupedit.pt?view=auto > > > > Oh, also, I guess it should use z3c.ptcompat rather than z3c.pt.compat > for z3c.pt thing. I have a branch for that, but am blocked on merging that because the z3c.ptcompat code has test failures (in itself and z3c.form). These test failures existed before I moved z3c.pt.compat to z3c.ptcompat. > > -- > WBR, Dan Korostelev > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security changes
On Sat, Jan 31, 2009 at 06:21:27AM -0500, Jim Fulton wrote: > > On Jan 30, 2009, at 1:48 PM, Brian Sutherland wrote: >> >> Please don't, having namespace packages that contain files (as >> zope.configuration already does) breaks setuptools. > > > zope.configuration isn't a namespace package. It is simply a package > with subpackages. I assumed Chris' suggestion was to make zope.configuration a namespace package. > > Jim > > -- > Jim Fulton > Zope Corporation > > -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security changes
On Fri, Jan 30, 2009 at 05:32:33PM +, Chris Withers wrote: > Martijn Faassen wrote: > >>> This makes a lot more sense to me than having the ZCML support in > >>> either zope.component or zope.security. > >> Indeed, surely all zcml stuff belongs in zope.configuration anyway? > > > > No, not there either, as zope.configuration doesn't define *any* > > directives except the basic ones like 'include' and 'configure'. If you > > would implement zope 3's directives in zope.configuration it'd start > > pulling in dependencies like crazies, creating more dependency cycles. > > > > I think a new package might be in order. > > Indeed, maybe: > > zope.configuration.x > zope.configuration.y Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools. > etc... > > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martijn Faassen wrote:
> > Christian Zagrodnick wrote:
> > [snip]
> >> Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
> >
> > Weird. At first glance I do not understand the context of that decision.
> > There was a decision to "avoid deprecation" made by it doesn't seem to
> > be motivated in the discussion:
> >
> > "- zope.app.component.interfaces then can import ISite from the new
> > place to avoid deprectation."
> >
> > You're saying, I think, that we should do the same thing as in that
> > discussion to avoid deprecation too. But I cannot find a reason to avoid
> > deprecation in the original discussion. Could you elaborate on your
> > thinking?
> >
> > I'm hoping to soon go through quite a few packages and deprecate lots of
> > stuff by moving it into other packages to try to tidy up the dependency
> > structure. If there are important arguments against deprecation warnings
> > I'd like to understand the background.
>
> One issue is that adding deprecation messages for importing symbols from
> the old makes all "downstream" code add ugly BBB warts in order to
> suppress them when run against multiple versions.
This is my issue as well.
http://docs.python.org/library/warnings.html#module-warnings
We could use PendingDeprecationWarning for recently deprecated code and
then convert that to DeprecationWarning once an alternative has been
available for some time.
That way, people like Roger would be able to get all recent deprecation
warnings by using the -Wd command line option to python, but they
wouldn't be shown by default.
# python2.4 -Wd
>>> import warnings
>>> warnings.warn("deprecated", PendingDeprecationWarning)
__main__:1: PendingDeprecationWarning: deprecated
# python2.4
>>> import warnings
>>> warnings.warn("deprecated", PendingDeprecationWarning)
There's probably some caveat as to why this won't work, but it seems
like it should by looking at the documentation.
--
Brian Sutherland
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.browser?
On Fri, Dec 12, 2008 at 02:24:09PM +0100, Martijn Faassen wrote: > Hey, > > Christian Zagrodnick wrote: > [snip] > > That's good. One thing which is not good is that you deprecated the use > > of ITerms from zope.app.form. I'd just leave the reference/import there > > like we did with ISite in zope.app.component. > > Why is such a deprecation warning bad? Wouldn't this encourage people to > update their code? One issue is that it's impossible to write code that's "deprecation warning free" and works across multiple versions of dependencies. That forces people to become accustomed to seeing and ignoring deprecation warnings. > > Regards, > > Martijn > > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.browser?
On Thu, Dec 11, 2008 at 03:20:25PM +0100, Martijn Faassen wrote: > I'm sure there's a bit of the plan I don't > understand yet - please enlighten me? AFAIKR, it's a package that mostly contains interfaces for well accepted browser design paradigms. That way different implementations can share the same interfaces. Obviously we've gotta be careful of what goes in there. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
On Wed, Dec 10, 2008 at 01:29:49PM -0500, Tres Seaver wrote: > Note that the __file__ of the namespace package is not guaranteed to be > in one or the other egg, which is why namespace packages must have > nothing more in their __init__.py than the boilerplate which declares > the namespace. With system packaged the __init__.py is guaranteed to not even be installed. Try this: $ python setup.py install --single-version-externally-managed --root xxx Also, if there are files alongside the __init__.py, they can cause filesystem conflicts in system packagers. dpkg will refuse to install a package if it would overwrite a file owned by another package. > > > > Tres > - -- > === > Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] > Palladion Software "Excellence by Design"http://palladion.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJQAqd+gerLs4ltQ4RAvHgAKCgjeyLLFqZUmhmhsd81Wm6RXlXyQCg2r0D > PNIFGNtvOwkYzsh9VSHEIy4= > =pcdI > -END PGP SIGNATURE- > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
On Tue, Dec 09, 2008 at 09:09:26PM +0100, Brian Sutherland wrote: > On Tue, Dec 09, 2008 at 04:31:33PM +0100, Malthe Borch wrote: > > 2008/12/9 Roger Ineichen <[EMAIL PROTECTED]>: > > > I agree > > > A package should never use another package as it's namespace. > > > Which means a package can not be both a package and namespace for > > > other packages. > > > > Seems to work fine for e.g. ``repoze.bfg``. > > It works under most situations, but not the ones that are important to > me. I've never tried to use repoze.bfg. > > > > Malthe are you aware of this? Can you change it? > > > > I do regret the package name and I would not be opposed to renaming it > > to z3c.ptcompat. > > Great, then sometime this week I'll: > * rename the package I've done this. > * upload a release to pypi I got caught on this, for 2 reasons: * The z3c.pt.compat tests are broken and were broken before I started. I don't want to release a package with broken tests. [1] * 93339 breaks the z3c.form tests [2] Below are the failures, Malthe, would you mind having a look at these? > * change the imports and dependencies in z3c.form I've done this on a branch for now. I'll have a look at the other z3c.* packages once this is all working. The test failures: [1] Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Failure in test /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/unittest.py", line 260, in run testMethod() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/doctest.py", line 2128, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for zcml.txt File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 0 -- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 27, in zcml.txt Failed example: factory.index Expected: Got: -- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 45, in zcml.txt Failed example: factory.index Expected: Got: -- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 70, in zcml.txt Failed example: factory.template Expected: Got: -- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 90, in zcml.txt Failed example: factory.template Expected: Got: -- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 111, in zcml.txt Failed example: factory.index Expected: Got: -- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 131, in zcml.txt Failed example: factory.index Expected: Got: [2] Failure in test /Users/jinty/src/z3c.form/src/z3c/form/tests/../form.txt Failed doctest test for form.txt File "/Users/jinty/src/z3c.form/src/z3c/form/tests/../form.txt", line 0 -- File "/Users/jinty/src/z3c.form/src/z3c/form/tests/../form.txt", line 478, in form.txt Failed example: print addForm.render() # doctest: +NOPARSE_MARKUP Expected: http://www.w3.org/1999/xhtml";> There were some errors. The id and name cannot be the same. ... Got: http://www.w3.org/1999/xhtml";> There were some errors. The id and name cannot be the same. ID Name Gender no value male female Age Diff: http://www.w3.org/1999/xhtml";> There were some errors. The id and name cannot be the same. - ID Name Gender no value male female Age
Re: [Zope-dev] z3c.form 2.0 release
On Wed, Dec 10, 2008 at 11:05:06AM +0100, Hermann Himmelbauer wrote: > Someone recently suggested to rename it to z3c.schema.iban, which sounds a > good idea to me, however, in this case my package would use another package, > namely z3c.schema, as namespace. > > So what's your suggestion in this case? There's no problem as long as z3c.schema is truly empty, i.e. there are no other packages that put any files in it. The problem with z3c.pt.compat is that z3c.pt is not empty (see http://svn.zope.org/z3c.pt/trunk/src/z3c/pt/). That's what causes the problems I've been seeing. > > Best Regards, > Hermann > > > > > -- > [EMAIL PROTECTED] > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
On Tue, Dec 09, 2008 at 04:31:33PM +0100, Malthe Borch wrote: > 2008/12/9 Roger Ineichen <[EMAIL PROTECTED]>: > > I agree > > A package should never use another package as it's namespace. > > Which means a package can not be both a package and namespace for > > other packages. > > Seems to work fine for e.g. ``repoze.bfg``. It works under most situations, but not the ones that are important to me. I've never tried to use repoze.bfg. > > Malthe are you aware of this? Can you change it? > > I do regret the package name and I would not be opposed to renaming it > to z3c.ptcompat. Great, then sometime this week I'll: * rename the package * upload a release to pypi * change the imports and dependencies in z3c.form Please let me know if there's a step I'm missing? > > \malthe > -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote: > On Friday 05 December 2008, Martin Aspeli wrote: > > Is there any indication on when we'll see a 2.0 release of z3c.form? > > > > We need a widget that's not in the 1.9 release, but is on trunk (for a > > list with textline value type), and are wondering whether to roll our > > own or wait for a new z3c.form release. > > I am considering the code feature complete. I would like to get confirmation > from people that (a) the z3c.pt integration works well I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package. The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be "merely a container for modules and subpackages." [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts. I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support. [1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages > and (b) the object > widget is useful. Oh yes, and since I have not done the development, are we > 100% test covered? > > BTW, at Keas we are currently using z3c.form trunk and it all looks okay. > > Regards, > Stephan > -- > Stephan Richter > Web Software Design, Development and Training > Google me. "Zope Stephan Richter" > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Fwd: Zope Tests: 4 OK, 2 Failed]
On Thu, Dec 04, 2008 at 04:21:51PM +0100, Wichert Akkerman wrote: > Previously Tres Seaver wrote: > > As an aside / vent: the reason for the now-removed EXTERNALS.txt files > > was to keep the canonical information about the externals in a diffable > > file: why subversion can't do a proper diff on its own line-oriented > > property is beyond me. Another benefit of an EXTERNALS.txt file was > > that it could be inspected in the web view of a directory, which isn't > > true for the svn:externals property itself. > > If only svn.zope.org had a trac-based browser, which does show those > properties properly... Like this one: http://zope3.pov.lt/trac/browser ? > > Wichert. > > -- > Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. > http://www.wiggy.net/ It is hard to make things simple. > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.index
On Tue, Dec 02, 2008 at 11:52:29AM -0500, Benji York wrote: > The status quo is to forgo creating extras unless there is a compelling > reason to have one. +10 -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy: Decoupling Zope3 and SQLAlchemy commit - how? Should I?
On Sun, Nov 02, 2008 at 09:37:56PM +0100, Hermann Himmelbauer wrote: > Hi, > In one of my Zope3 projects, I use lovely.remotetask to run specific tasks in > background. These tasks do lengthy database operations via zope.sqlalchemy. > Currently, lovely.remotetask seems to do a Zope3 commit() at the end of the > task, which also does the SQLAlchemy commit. > > However, some tasks consist of a loop over self-contained operations, > therefore it would be handy to commit after each such operation. This way, if > one of the operations fail (e.g. due to some database error, such as locking, > refrential integrity violation etc.), not the whole task is rolled back but > only one operation. Moreover, the probability of database locks is reduced. I've never used lovely.remotetask, but I would suggest trying: * Have your "loop over self-contained operations" create more tasks. * Move the loop to the application and create many tasks, one for each operation. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy locks up transaction
On Thu, Sep 18, 2008 at 07:08:56AM +0200, Dieter Maurer wrote: > Brian Sutherland wrote at 2008-9-17 12:33 +0200: > >On Tue, Sep 16, 2008 at 02:01:07PM +0100, Laurence Rowe wrote: > >> Brian Sutherland wrote: > >> > Hi, > >> > > >> > I've recently seen a situation where zope.sqlalchemy locked up the > >> > transaction machinery. I'm not sure exactly what happened, but have > >> > attached a failing test for at least one bug which may have caused it. > >> > Hopefully it's self explanatory;) > >> > > >> > If someone could help me solve this, that would be great! > >> > >> Could you try this with latest trunk. I checked in a fix the other day > >> that may help. > > > >I just checked in a fix, please feel free to comment on/revert it if > >it's not up to standard:) > > It looks not yet right to clear the state in "tpc_vote" when > a two phase commit is used (which is now supported by "SQLAlchemy"). It looks to me that in a two phase commit, the tpc_vote which is called is: def tpc_vote(self, trans): if self.tx is not None: # there may have been no work to do self.tx.prepare() self.state = 'voted' is that what you mean by clearing state? > In addition, there may be a problem in case "session.close()" raises > an exception. Then, "_finish" would not be called. I modified my patch, moving session.close() into _finish and actually calling close() after the state is cleared. That way, the errors can propagate, but the transaction will not get wedged. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy locks up transaction
On Tue, Sep 16, 2008 at 02:01:07PM +0100, Laurence Rowe wrote: > Brian Sutherland wrote: > > Hi, > > > > I've recently seen a situation where zope.sqlalchemy locked up the > > transaction machinery. I'm not sure exactly what happened, but have > > attached a failing test for at least one bug which may have caused it. > > Hopefully it's self explanatory;) > > > > If someone could help me solve this, that would be great! > > Could you try this with latest trunk. I checked in a fix the other day > that may help. I just checked in a fix, please feel free to comment on/revert it if it's not up to standard:) > > Laurence > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
On Wed, Sep 03, 2008 at 05:18:50PM +0200, Hermann Himmelbauer wrote: > Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland: > > On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: > > > Hi, > > > In my current SQLAlchemy / Zope-based design, I need the following: > > > > > > - SQLAlchemy table definitions > > > - classes + mappers > > > - Zope interfaces > > > > > > The problem with this design is that much data has to be defined twice, > > > e.g. the datatype "varchar(50)" should be represented by an interface > > > with TextLine(max_length="50"). Moreover, any changes such as adding > > > columns etc. also have to be done in the interface and the table > > > definition. > > > > > > To overcome this, I just had the idea to use the interface/schema > > > definitions for the table definition itself. Probably I'm not the first > > > who had this idea, but I'm not aware of such an extension to interfaces. > > > > > > Any thoughts on this? > > > > I'm much more in favour of the reverse procedure. I think the database > > is the canonical store of this information and that SQLAlchemy should > > read that and make it available for doing form validation. > > But isn't exactly that the real meaning of interfaces? > So I have the impression that at the beginning of the design process, I'd > model the interfaces, which describe and express everything I expect from the > underlying objects. > > And when that is done, I'd program the underlying objects. And for content > objects, the storage could be in an RDB (SQLAlchemy), or somewhere else. And > for that, the table structure could be derived from the interface. Trying to derive an RDB table structure from an object model's design has nearly always left me with badly designed and/or badly performing database tables. Every time, it's paid me to design the database structure to be application independent. Basically assume that your application will never be the only application using the database. Many projects have a way of sprawling and having a database usable by non-application code is a big advantage. So, given that I believe the above, trying to use the application to create an application independent database schema is the wrong way around. > If I model it the other way round, the power of interfaces is somehow > crippled: > > - The tables can already be documented in the table declaration itself, so > the > interfaces are only useful for extra documentation, such as mapper properties > and class properties. > - The interface values are of mediocre value for forms, too, as the forms > will often need a change of the schema. (E.g. think of an add person form, > where the name is required and in comparison a search form, where the name > may not be required and thus the name-schema cannot be 1:1 used, or, even > simpler, think of a change of the title). I currently either copy the schemas > into my form, or even write separate interfaces. > - The real reason I need the interfaces is that I have to include them in my > configure.zcml in order to make the underlying objects read/writeable. But > this is in my case only annoying, but not helpful at all. > > Best Regards, > Hermann > > -- > [EMAIL PROTECTED] > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: > Hi, > In my current SQLAlchemy / Zope-based design, I need the following: > > - SQLAlchemy table definitions > - classes + mappers > - Zope interfaces > > The problem with this design is that much data has to be defined twice, e.g. > the datatype "varchar(50)" should be represented by an interface with > TextLine(max_length="50"). Moreover, any changes such as adding columns etc. > also have to be done in the interface and the table definition. > > To overcome this, I just had the idea to use the interface/schema definitions > for the table definition itself. Probably I'm not the first who had this > idea, but I'm not aware of such an extension to interfaces. > > Any thoughts on this? I'm much more in favour of the reverse procedure. I think the database is the canonical store of this information and that SQLAlchemy should read that and make it available for doing form validation. > > Best Regards, > Hermann > > -- > [EMAIL PROTECTED] > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] transaction.doom() and ZPublisher
On Sat, Jul 12, 2008 at 07:17:31AM +0200, Andreas Jung wrote: > > > --On 10. Juli 2008 17:09:36 +0200 Brian Sutherland > <[EMAIL PROTECTED]> wrote: > >> On Thu, Jul 10, 2008 at 12:12:06AM -0400, Paul Winkler wrote: >>> Hi, > > >> >> I havn't investigated properly, but it may be necessary to do the >> isDoomed() check at a higher level where you can abort. > > What do you mean by "higher level"? I think that the check within the > ZPublisher is the highest and right place. Ok, as I said, I havn't investigated properly. >> Code running >> after the commit() expects a new transaction and now will not get that. > > You refer to code executed as part of a ZODB post-commit handler? > If a transaction is doomed then such handlers should never be executed - > right? If I see a function named "commit" I expect that calling it will cause a commit, or raise an error. I don't expect that nothing will happen and I will have the same transaction after as before. So this part of the patch: def commit(self): -transaction.commit() +if not transaction.get().isDoomed(): +transaction.commit() Changes the meaning of the commit() function from "Commit or error" to "maybe commit, or maybe do nothing, or maybe error". That raises lots of warning bells in my head. But, it's probably OK, depending on what the code calling commit() expects. > > > Andreas -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
