[Zope3-dev] Re: 'thread_local' AttributeError in zope.security.checker

2007-08-15 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Aug 14, 2007, at 7:32 PM, Paul Carduner wrote:
 
 Hello zope3-dev,

 I came across an error I have not seen before.  Just for reference,
 here is the last snippet from the traceback:

 File /home/pcardune/Work/ZContact/zcontact-lp/eggs/tmpgwuq6O/ 
 zope.security-3.4.0b4-py2.4-linux-i686.egg/zope/security/checker.py,
 line 420, in ?
 AttributeError: 'module' object has no attribute 'thread_local'
 
 I wish you had included the whole traceback.
 
 
 The interesting part to me is that it was so easy to fix.  Here is a
 snippet of the relevant area of failing code from
 zope/security/checker.py

 # Get optimized versions
 try:
 import zope.security._zope_security_checker
 except ImportError:
 pass
 else:
 from zope.security._zope_security_checker import _checkers,  
 selectChecker
 from zope.security._zope_security_checker import NoProxy, Checker
 from zope.security._zope_security_checker import _defaultChecker
 from zope.security._zope_security_checker import  
 _available_by_default
 zope.interface.classImplements(Checker, INameBasedChecker)

 The very first import statement is throwing the error, but alas, it is
 not an ImportError.  If I patch this code by catching the
 AttributeError in the same way the ImportError is caught, then
 everything works fine.
 
 Except you don't get the C optimizations. IOW, you would just be  
 covering up a real error.
 
 
 I tried looking into the c code, but after
 years of python development, the c code just frightens me (a bit).
 That said, I would really appreciate any pointers people might be able
 to give me on what thread_local is for and why I (don't) need it.
 
 I rearranged the imports in zope.security yesterday.  I apparently  
 broke your usage, but I can't tell what your usage is.  I'll need to  
 see the whole traceback.  In particular, I'll need to see the import  
 order.

We badly need to get a handle on how we expect people to fetch eggs for
packages:  having such a refactoring affect an indirect client (one not
expecting to track day-to-day development) is a disaster.

Dumping revision-stamped (unreleased) eggs into a directory used by
unsuspecting users is a recipe for bringing *all* development to a
screeching halt.


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

iD8DBQFGww8E+gerLs4ltQ4RAizUAJ4/g04M14f9pI2QA/NAub2CwrVtDwCfQ2cD
dQNNFuvkirf3sbAWOuC7/VE=
=YjyB
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: 'thread_local' AttributeError in zope.security.checker

2007-08-15 Thread Jim Fulton


On Aug 15, 2007, at 10:34 AM, Tres Seaver wrote:
...
We badly need to get a handle on how we expect people to fetch eggs  
for
packages:  having such a refactoring affect an indirect client (one  
not

expecting to track day-to-day development) is a disaster.


I'm not sure disaster is the word I'd use, but in general, I agree.


Dumping revision-stamped (unreleased) eggs into a directory used by
unsuspecting users is a recipe for bringing *all* development to a
screeching halt.


Yeah, I need to release the buildout changes that makes buildout  
prefer released eggs.


Note that in this particular case, the real problem was circular  
imports.  Circular imports create bugs that are hard or impossible to  
test for.  I'd love to outlaw them.  I wish we at least had a tool to  
warn about circular imports when testing.


Jim

--
Jim Fulton  mailto:[EMAIL PROTECTED]Python 
Powered!
CTO (540) 361-1714  
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org



___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com