Re: [Zope-dev] zope-tests - FAILED: 4, OK: 8

2013-09-10 Thread Brian Sutherland
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

2013-04-23 Thread Brian Sutherland
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

2013-04-15 Thread Brian Sutherland
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

2013-04-12 Thread Brian Sutherland
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

2013-03-19 Thread Brian Sutherland
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

2013-03-05 Thread Brian Sutherland
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

2013-03-05 Thread Brian Sutherland
On Tue, Mar 05, 2013 at 05:56:54PM +0200, Andrey Lebedev wrote:
 On 03/05/2013 05:10 PM, Brian Sutherland wrote:
 So far, it seems webtest has all the features needed to do the
 switch. I started a branch at github ([2]) to track work in
 progress. The goal is to make most (say 80%) of existing tests to
 work without modifications under new implementation.
 
 Looking at the branch, it seems that this is basically going to be a
 re-write of the existing code.
 
 Yes, it is a re-write, but not re-write from scratch. I use existing
 code as much as possible.
 
 You're planning to keep the mechanize backend available?
 
 Initially we didn't plan to keep mechanize. I think it would add an
 unjustified burden of choice to users (which backend to pick, if
 they work the same way?) and mechanize backend will/may not work in
 python3 anyway.
 
 The question of how compatible the webtest-based implementation will
 be, is still an open one though. However, we have a big real-world
 project to test compatibility against.

You're right, the big question is how compatible the WebTest version
will be. I don't think anyone will object to a drop-in replacement.
Having to modify 20% of existing tests sounds like a lot.  I guess we'll
have to see how compatible the new browser will be.

I'm willing to pitch in by testing it against my own application, please
let me know when/if you want me to do that.

 Might I suggest zope.testbrowser.webtest for the WebTest backed
 testbrowser rather than zope.testbrowser.browser2?
 
 I admit there is a bit of mess right now in the branch as I need to
 preserve existing code to copy when applicable. My plan is to rename
 z.t.browser2 to z.t.browser eventually, so it is not a final name.

Ok!

 Could you also keep the tests for the mechanize testbrowser intact?
 They could be skipped if mechanize is not importable and mechanize
 downgraded to an optional dependency.
 
 Again, if the compatibility of new implementation is proven to be
 good enough, I see no reason to keep mechanize around. I might
 miss some important reasons, though.

One thing which I'm not sure you can do with a webtest backend is using
it as a real browser. i.e. you'll probably not get over_the_wire.txt to
pass. However, I don't know of anyone who actually uses that
functionality.

Hmm, though I guess you can have a WSGI application that fires off real
HTTP requests...

-- 
Brian Sutherland
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Switching zope.testbrowser to webtest instead of mechanize

2013-03-05 Thread Brian Sutherland
On Tue, Mar 05, 2013 at 06:49:35PM +0200, Andrey Lebedev wrote:
 On 03/05/2013 06:45 PM, Brian Sutherland wrote:
 One thing which I'm not sure you can do with a webtest backend is using
 it as a real browser. i.e. you'll probably not get over_the_wire.txt to
 pass. However, I don't know of anyone who actually uses that
 functionality.
 
 Hm, webtest claims it can do this [1], but I haven't tested it myself yet.
 
 [1] 
 http://webtest.pythonpaste.org/en/latest/testapp.html#testing-a-non-wsgi-application

Nice!

-- 
Brian Sutherland
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.security

2013-02-12 Thread Brian Sutherland
 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

2013-01-10 Thread Brian Sutherland
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.

2012-05-21 Thread Brian Sutherland
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

2012-05-07 Thread Brian Sutherland
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

2012-04-26 Thread Brian Sutherland
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

2012-04-26 Thread Brian Sutherland
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

2012-04-13 Thread Brian Sutherland
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?

2012-04-11 Thread Brian Sutherland
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)

2012-04-10 Thread Brian Sutherland
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)

2012-04-09 Thread Brian Sutherland
://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

2012-03-27 Thread Brian Sutherland
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

2012-03-22 Thread Brian Sutherland
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?

2011-12-20 Thread Brian Sutherland
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

2011-12-05 Thread Brian Sutherland
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

2011-11-14 Thread Brian Sutherland
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

2011-11-14 Thread Brian Sutherland
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

2011-11-07 Thread Brian Sutherland
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

2011-11-07 Thread Brian Sutherland
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

2011-10-24 Thread Brian Sutherland
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

2011-10-14 Thread Brian Sutherland
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

2011-10-11 Thread Brian Sutherland
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

2011-10-10 Thread Brian Sutherland
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

2011-07-22 Thread Brian Sutherland
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

2011-07-22 Thread Brian Sutherland
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?

2011-07-12 Thread Brian Sutherland
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

2011-04-21 Thread Brian Sutherland
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

2011-03-29 Thread Brian Sutherland
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)

2011-03-16 Thread Brian Sutherland
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)

2011-03-10 Thread Brian Sutherland
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)

2011-03-10 Thread Brian Sutherland
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)

2011-03-07 Thread Brian Sutherland
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)

2011-03-04 Thread Brian Sutherland
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)

2011-03-04 Thread Brian Sutherland
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)

2011-03-04 Thread Brian Sutherland
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

2011-02-12 Thread Brian Sutherland
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)

2011-02-12 Thread Brian Sutherland
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)

2011-02-02 Thread Brian Sutherland
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)

2011-01-31 Thread Brian Sutherland
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)

2011-01-30 Thread Brian Sutherland
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

2010-12-15 Thread Brian Sutherland
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

2010-12-15 Thread Brian Sutherland
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

2010-12-15 Thread Brian Sutherland
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

2010-12-15 Thread Brian Sutherland
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

2010-11-11 Thread Brian Sutherland
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

2010-11-11 Thread Brian Sutherland
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

2010-11-09 Thread Brian Sutherland
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

2010-11-09 Thread Brian Sutherland
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

2010-11-09 Thread Brian Sutherland
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

2010-11-08 Thread Brian Sutherland
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

2010-08-30 Thread Brian Sutherland
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

2010-08-02 Thread Brian Sutherland
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

2010-03-04 Thread Brian Sutherland
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

2010-03-04 Thread Brian Sutherland
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

2010-03-04 Thread Brian Sutherland
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

2010-03-03 Thread Brian Sutherland
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

2010-03-02 Thread Brian Sutherland
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

2010-02-23 Thread Brian Sutherland
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.

2010-02-11 Thread Brian Sutherland
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

2009-12-17 Thread Brian Sutherland
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

2009-12-17 Thread Brian Sutherland
 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

2009-12-03 Thread Brian Sutherland
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

2009-12-03 Thread Brian Sutherland
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

2009-11-30 Thread Brian Sutherland
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

2009-11-25 Thread Brian Sutherland
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

2009-06-22 Thread Brian Sutherland
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

2009-06-22 Thread Brian Sutherland
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

2009-06-15 Thread Brian Sutherland
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

2009-04-03 Thread Brian Sutherland
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?

2009-03-12 Thread Brian Sutherland
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

2009-02-09 Thread Brian Sutherland
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

2009-02-09 Thread Brian Sutherland
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

2009-01-31 Thread Brian Sutherland
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

2009-01-30 Thread Brian Sutherland
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?]

2008-12-17 Thread Brian Sutherland
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?

2008-12-12 Thread Brian Sutherland
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?

2008-12-11 Thread Brian Sutherland
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

2008-12-10 Thread Brian Sutherland
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

2008-12-10 Thread Brian Sutherland
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

2008-12-10 Thread Brian Sutherland
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

2008-12-09 Thread Brian Sutherland
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

2008-12-09 Thread Brian Sutherland
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]

2008-12-04 Thread Brian Sutherland
On Thu, Dec 04, 2008 at 04:21:51PM +0100, Wichert Akkerman wrote:
 Previously Tres Seaver wrote:
  As an aside / vent:  the reason for the now-removed EXTERNALS.txt files
  was to keep the canonical information about the externals in a diffable
  file:  why subversion can't do a proper diff on its own line-oriented
  property is beyond me.  Another benefit of an EXTERNALS.txt file was
  that it could be inspected in the web view of a directory, which isn't
  true for the svn:externals property itself.
 
 If only svn.zope.org had a trac-based browser, which does show those
 properties properly...

Like this one: http://zope3.pov.lt/trac/browser

?

 
 Wichert.
 
 -- 
 Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
 http://www.wiggy.net/   It is hard to make things simple.
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )

-- 
Brian Sutherland
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.index

2008-12-02 Thread Brian Sutherland
On Tue, Dec 02, 2008 at 11:52:29AM -0500, Benji York wrote:
 The status quo is to forgo creating extras unless there is a compelling
 reason to have one.

+10

-- 
Brian Sutherland
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.sqlalchemy locks up transaction

2008-09-18 Thread Brian Sutherland
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

2008-09-17 Thread Brian Sutherland
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

2008-09-04 Thread Brian Sutherland
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

2008-09-03 Thread 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.

 
 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

2008-07-13 Thread Brian Sutherland
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

2008-07-13 Thread Brian Sutherland
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] transaction.doom() and ZPublisher

2008-07-10 Thread Brian Sutherland
On Thu, Jul 10, 2008 at 12:12:06AM -0400, Paul Winkler wrote:
 Hi,
 
 I noticed that Zope 2.11 includes a recent version of the transaction
 module including the transaction.doom() method.  But I don't see any
 check for it in ZPublisher.
 
 So, if any code calls transaction.doom(), the publisher will raise a
 user-visible exception when it tries to call commit().  This seems
 less than useful :-)
 
 In the discussion I've seen of this method, eg.
 https://bugs.launchpad.net/zope3/+bug/98382 and
 http://markmail.org/message/3yshpmltvhevnrff it sounds like other
 people share my expectation... namely, that the developer should not
 have to do anything special after calling transaction.doom(); the
 transaction is not committed, and the user won't see an exception.

Yes.

 
 Is that the concensus? If so, there's an easy solution -
 apply something like the attached patch.
 
 Anybody disagree?

I havn't investigated properly, but it may be necessary to do the
isDoomed() check at a higher level where you can abort. Code running
after the commit() expects a new transaction and now will not get that.

Other than that, an explicit abort() if the transaction is doomed may be
sufficient.

Zope3 does:

 def afterCall(self, request, ob):
 txn = transaction.get()
if txn.isDoomed():
txn.abort()
else:
self.annotateTransaction(txn, request, ob)
txn.commit()

 
 
 -- 
 
 Paul Winkler
 http://www.slinkp.com

 --- Zope2/App/startup.py~ 2008-06-14 02:50:23.0 -0400
 +++ Zope2/App/startup.py  2008-07-10 00:08:02.0 -0400
 @@ -267,7 +267,8 @@
  transaction.begin()
  
  def commit(self):
 -transaction.commit()
 +if not transaction.isDoomed():
 +transaction.commit()
  
  def abort(self):
  transaction.abort()
 --- ZPublisher/Publish.py~2008-06-14 02:50:48.0 -0400
 +++ ZPublisher/Publish.py 2008-07-10 00:08:08.0 -0400
 @@ -314,7 +314,8 @@
  def begin(self):
  transaction.begin()
  def commit(self):
 -transaction.commit()
 +if not transaction.get().isDoomed():
 +transaction.commit()
  def abort(self):
  transaction.abort()
  def recordMetaData(self, object, request):
 --- ZPublisher/WSGIPublisher.py~  2008-06-14 02:50:48.0 -0400
 +++ ZPublisher/WSGIPublisher.py   2008-07-09 23:59:57.0 -0400
 @@ -401,7 +401,8 @@
  def begin(self):
  transaction.begin()
  def commit(self):
 -transaction.commit()
 +if not transaction.get().isDoomed():
 +transaction.commit()
  def abort(self):
  transaction.abort()
  def recordMetaData(self, object, request):

 ___
 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: created z3c.saconfig

2008-06-21 Thread Brian Sutherland
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

2008-06-20 Thread Brian Sutherland
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 )


  1   2   >