More on Numexpr-unsupported objects

Tim Hochberg tim.hochberg at
Tue Nov 7 14:38:39 CST 2006

Ivan Vilata i Balaguer wrote:

> Though I admit it may be strange for this error to be triggered.
> (I had a little mess with using ``expressions.ExpressionNode`` instead
> of ``expr.ExpressionNode``...  I still don't see why the private copy of
> the module is necessary.)
It's an attempt to make things thread safe. Since we are mucking around 
with the internals of the expression module, if there were multiple 
threads one might thread might change get_context out from under the 
other one. Giving each call to stringToExpression its own copy of the 
expression module prevents this.

It is,  admittedly, a kind of stupid way to do this. A more sane thing 
to do would probably to have some sort of expression object that we 
instantiate for each call to stringToExpression instead of mucking 
around with modules, which really aren't meant to be (ab)used this way. 
However, this would require a major rewrite of the expression module and 
I was feeling lazy at the time (and still am), so I resorted to 
questionable hackery.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

More information about the Numpy-discussion mailing list