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 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] 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] 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 tsea...@palladion.com 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)
class '漢語.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 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 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)
class '漢語.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 Designhttp://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:
-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 ha...@hannosch.eu writes: On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver tsea...@palladion.com 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 br...@vanguardistas.net 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)
://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__ (InterfaceClass zope.schema.interfaces.IContextSourceBinder, InterfaceClass zope.interface.Interface) 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 chr...@plope.com [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: 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 module '--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 module 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 module import zope.exceptions.exceptionformatter File /tmp/zft/eggs/zope.exceptions-3.6.1-py2.5.egg/zope/exceptions/__init__.py, line 24, in module import zope.security File /tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/__init__.py, line 17, in module 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 module 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 module 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 module 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-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.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.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 br...@vanguardistas.net 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-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 br...@vanguardistas.net 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) class '漢語.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 )
[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 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=uParent 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=uParent 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] 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] 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] 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 br...@vanguardistas.net 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 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 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)
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 br...@vanguardistas.net 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 br...@vanguardistas.net 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 Ok, committed this. I've also allowed domains like test.example.com. In order to run the tests on the groktoolkit trunk, run: bin/buildout sources:zope.testbrowser=svn svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3 sources:zope.app.wsgi=svn svn+ssh://svn.zope.org/repos/main/zope.app.wsgi/branches/janjaapdriessen-webtest buildout:auto-checkout=zope.testbrowser zope.app.wsgi grok grokcore.rest versions:WebTest=1.2.3 bin/test-grok -- Jan-Jaap Driessen 1) http://zope3.pov.lt/trac/changeset/120756/zope.app.wsgi/branches/janjaapdriessen-webtest/src/zope/app/wsgi/testlayer.py 2) http://zope3.pov.lt/trac/changeset/119878/zope.app.wsgi/trunk/src/zope/app/wsgi/testlayer.py -- Brian
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 br...@vanguardistas.net [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/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. Great! I would much prefer to merge both steps together. Yes, I guess that makes sense because only step (b) includes proper tests for everything. Perfect. Wolfgang
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 w...@gocept.com wrote: Hello Brian, Hello, it's taken a while, but I finally had a chance to review your branch(es). * Brian Sutherland br...@vanguardistas.net [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 Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote: Hello, On Fri, 4 Mar 2011 10:15:18 +0100 Brian Sutherland br...@vanguardistas.net 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] 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 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 br...@vanguardistas.net [2011-02-02 11:15]: On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: * Brian Sutherland br...@vanguardistas.net [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] zope.testbrowser and WebTest (round 2)
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: * Brian Sutherland br...@vanguardistas.net [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 br...@vanguardistas.net [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.checker, package='zope.testbrowser') +wsgi_suite = doctest.DocFileSuite( +'README.txt', +'cookies.txt', +'wsgi.txt', +'fixed-bugs.txt', +optionflags=flags, +globs=dict(Browser=zope.testbrowser.wsgi.Browser), +checker=zope.testbrowser.tests.helper.checker
[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 )
[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.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 br...@vanguardistas.net 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 )
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 Thu, Dec 16, 2010 at 12:06:36AM +0100, Hanno Schlichting wrote:
On Wed, Dec 15, 2010 at 2:06 PM, Brian Sutherland
br...@vanguardistas.net 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] 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:07:00PM +0100, Charlie Clark wrote: Am 10.11.2010, 01:40 Uhr, schrieb Brian Sutherland br...@vanguardistas.net: 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] 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 = \
from zope.interface import Interface, Attribute
class I1(Interface):
pass
s1 = \
I1.queryTaggedValue('bob')
t = timeit.Timer(stmt=s1, setup=setup)
print query uninitialized tagged value: %.2f usec/pass % (100 *
t.timeit(number=5)/5)
setup = \
from zope.interface import Interface, Attribute
class I1(Interface):
pass
I1.setTaggedValue('bob', 'bobby')
s1 = \
I1.queryTaggedValue('bob')
t = timeit.Timer(stmt=s1, setup=setup)
print
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
br...@vanguardistas.net:
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 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 )
[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 10:09:26AM -0500, Jim Fulton wrote: On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune c...@gocept.com 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] 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 br...@vanguardistas.net 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 11:19:52AM -0500, Benji York wrote: On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland br...@vanguardistas.net 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] 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 m...@rpatterson.net 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=105324view=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 m...@ronin-group.org 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] 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] Interfaces vs ZCA concepts
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] 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] 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] 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 tsea...@palladion.com 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 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 )
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 )
[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=1397view=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 10:52:01AM +0300, Dan Korostelev wrote: 2009/2/9 Dan Korostelev nad...@gmail.com: 2009/2/9 Stephan Richter srich...@cosmos.phy.tufts.edu: 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] 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] 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 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 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: z3c.ptcompat.ViewPageTemplateFile object at ... Got: z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt' -- File /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt, line 45, in zcml.txt Failed example: factory.index Expected: z3c.ptcompat.ViewPageTemplateFile object at ... Got: z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt' -- File /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt, line 70, in zcml.txt Failed example: factory.template Expected: z3c.ptcompat.ViewPageTemplateFile object at ... Got: z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt' -- File /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt, line 90, in zcml.txt Failed example: factory.template Expected: z3c.ptcompat.ViewPageTemplateFile object at ... Got: z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt' -- File /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt, line 111, in zcml.txt Failed example: factory.index Expected: z3c.ptcompat.ViewPageTemplateFile object at ... Got: z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt' -- File /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt, line 131, in zcml.txt Failed example: factory.index Expected: z3c.ptcompat.ViewPageTemplateFile object at ... Got: z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt' [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: html xmlns=http://www.w3.org/1999/xhtml; body iThere were some errors./i ul li div class=errorThe id and name cannot be the same./div /li /ul ... /body /html Got: html xmlns=http://www.w3.org/1999/xhtml; body iThere were some errors./i ul li div class=errorThe id and name cannot be the same./div /li /ul form action=. div class=row label for=form-widgets-idID/label
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 Designhttp://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 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] 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] [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.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 Sun, Jul 13, 2008 at 09:05:16AM +0200, Dieter Maurer wrote: Andreas Jung wrote at 2008-7-12 07:17 +0200: ... What do you mean by higher level? I think that the check within the ZPublisher is the highest and right place. 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? The problem is that a doomed transaction prevents joining. This means that any operation that causes a join during error handling will fail. Examples are: accessing a session, accessing a relational database. The bug is in the ZODB (transaction) code. A doomed transaction should not prevent joining. Do you have an example of this bug? It should be fixed. It is already tested in doom.txt like this: A doomed transaction should act the same as an active transaction, so we should be able to join it: txn = transaction.begin() txn.doom() dm2 = DataManager() txn.join(dm2) But perhaps there is another way to make it fail? The only justification for the prevention is that transaction knows that any modification (potential cause of the join) will not be able to be committed (thus, transaction can indicate a problem earlier). *HOWEVER*, transactions can be joined for other purposes as modifications (example relational database access) and sometimes modifications should be possible even then they cannot be (and are not expected to be) committed (example error handling). Yep, you should still be able to join doomed transactions. According to the first line of doom.txt, the intention of doom is: A doomed transaction behaves exactly the same way as an active transaction but raises an error on any attempt to commit it, thus forcing an abort. Thus, please let us fix transaction. -- Dieter -- 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 )
Re: [Zope-dev] Re: created z3c.saconfig
On Fri, Jun 20, 2008 at 02:01:52PM +0200, Martijn Faassen wrote: Hi there, Brian Sutherland wrote: [snip] Also for this problem: # XXX what happens if EngineFactory were to be evicted from the ZODB # cache? def getCached(self): return getattr(self, '_v_engine', None) I think you could use the same mechanism found in zope.app.cache.ram. I.e. store the engines in a module level global dictionary. Then use some clever way (with a counter and time) to figure out a unique key for your local utility (and persistently store the key). Ah, thanks for that tip. Does zope.app.cache.ram deal with threading issues? Ah, yes, I see it uses a lock. Anyway, a patch would be welcome. :) Committed, please feel free to revert or modify as you feel:) 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] created z3c.saconfig
On Thu, Jun 19, 2008 at 08:51:17PM +0200, Martijn Faassen wrote: Hi there, I'd like to announce my contribution for the expanding list of options for SQLAlchemy integration for Zope 3. Looks good, I'd like to vote for moving some parts of it to zope.sqlalchemy. Namely z3c.saconfig.interfaces.IScopedSession and the entirety of z3c.saconfig.scopedsession. Also for this problem: # XXX what happens if EngineFactory were to be evicted from the ZODB # cache? def getCached(self): return getattr(self, '_v_engine', None) I think you could use the same mechanism found in zope.app.cache.ram. I.e. store the engines in a module level global dictionary. Then use some clever way (with a counter and time) to figure out a unique key for your local utility (and persistently store the key). -- 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] SQLAlchemy integration experiment
On Mon, Jun 16, 2008 at 08:40:24PM +0200, Martijn Faassen wrote: Hi there, In some earlier discussions a number of approaches to integrate SQLAlchemy into Zope were discussed. Following up on that, I've tried a particular approach that tries to use ScopedSessions with a custom scope that isn't just per thread, but also per site (application). The benefit of this approach is that it should allow the following to just work: from z3c.sa_integration import Session ... def somewhere_in_a_view(self): session = Session() return session.query(Test).all() For some reason this raises a warning bell in my head. I keep on thinking: this is zope, the session is a classic case for a utility, we should be getting it in views by an interface. That may be because I've already become too fixed in the way I think about things. However, Laurence's point about database re-connection is relevant here. If the Session were looked up by an interface, someone could implement seamless database re-connection (lots of complex code) without polluting zope.sqlalchemy. where 'Session' is a custom SA scoped session. I've checked in my (documented) experiment in here: svn://svn.zope.org/repos/main/Sandbox/faassen/rdbintegration/trunk The interesting bits are here: http://svn.zope.org/Sandbox/faassen/rdbintegration/trunk/src/rdbintegration/app.py This looks very nice. I'm not sure IDatabase.engine is necessary, it seems to be only used internally to Database. Also, any view code should really be getting the connection directly from the session. See the documentation in that file for more information. The one bit I'm not happy about yet is the way engines need to be global utilities now. I'd like it to be possible for users to edit the database connection parameters through the web. I have a sketchy idea about how to solve this by registering engines as non-persistent local utilities, but it's still unclear how they'd get created at the right time. It might also be possible to simply implement the engine method on IDatabase to create the engine when called the first time, and then cache it in a volatile property. I think this is something Laurence Rowe has been talking about. I'm not sure whether it's a good idea to rely on the ZODB cache, but it might be possible to simply cache the engines in a global registry... Comments? Suggestions? As Laurence has suggested, the session persists, so IDatabase.configuration will only be called once per thread. Not sure if creating one new engine per thread is bad. 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] Re: SQLAlchemy integration experiment
On Tue, Jun 17, 2008 at 11:52:49AM +0200, Martijn Faassen wrote: However, Laurence's point about database re-connection is relevant here. If the Session were looked up by an interface, someone could implement seamless database re-connection (lots of complex code) without polluting zope.sqlalchemy. And what is seamless database re-connection and why is this a job for Zope and not for SQLAlchemy? I mean in the situation where you change the database connection parameters on an existing connection and don't want to restart zope to use the new connection parameters. Why people seem to want the above escapes me, but people do seem to want it. I totally agree that Zope should not be responsible for re-connecting on error. where 'Session' is a custom SA scoped session. I've checked in my (documented) experiment in here: svn://svn.zope.org/repos/main/Sandbox/faassen/rdbintegration/trunk The interesting bits are here: http://svn.zope.org/Sandbox/faassen/rdbintegration/trunk/src/rdbintegration/app.py This looks very nice. I'm not sure IDatabase.engine is necessary, it seems to be only used internally to Database. Yes, but it is policy someone may want to change. In this case I implemented the policy to look up the engine by name, but it might be the default policy would be to simply look up IEngine locally or something. Just commenting that IDatabase.engine is not used by any code external to the Database object. There's no use case for it to be public. Also, any view code should really be getting the connection directly from the session. I don't understand that what you mean by 'connection'. Oh, you mean which engine is used? That's really just some testing code, I imagine it could directly manipulate the session in realer code. I was more thinking if you wanted to execute raw sql from a view class you would do that via the engine. But it seems that the session has an execute() method for that. [snip] As Laurence has suggested, the session persists, so IDatabase.configuration will only be called once per thread. Not sure if creating one new engine per thread is bad. I don't know either. I've assumed that one wouldn't want to recreate the engine for each thread, but perhaps that's fine and we don't break any, say, connection pooling mechanisms that way? I do not know. Unfortunately I don't either... 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] Re: SQLAlchemy integration experiment
On Tue, Jun 17, 2008 at 11:58:56AM +0200, Martijn Faassen wrote: Anyway, the balance can come out somewhere else. People are free to write their own integration approaches, it's just that mine is actually about trying to make exactly this pattern work in the first place. Then when I succeed people want it changed. :) Anyway, no surprise: I knew that some want other patterns, and I'll be curious to see the other approaches as well. Hmm, how about this approach. It builds on and is almost compatible with yours, but allows me a plug in point where I need it. My use case is the simplest in that I have no local utilities and no need of application scoped sessions (plain old thread scoping works just fine). But I would like to have the option of using code others write for zope/sqlalchemy and allow others to use our code. The total code I would write in zope.sqlalchemy would be this: class ISession(Interface): def __call__(): Return a SQLAlchemy Session object def Session(): return getUtility(ISession)() I would use it in view code like: from zope.sqlalchemy import Session class View: def some_view_method(self): session = Session() session.do_stuff() I do believe that the application scoping approach you showed us could be implemented by registering your session as the ISession utility. It may be that zope.sqlalchemy provides different implementations of sessions, but I would prefer to see no ISession utility actually registered. 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 )
