numpy-discussion

[Numpy-discussion] More on Numexpr-unsupported objects

[Ivan V. i B. <iv...@ca...>]

This is somehow related with this previous thread about raising
``TypeError`` on unsupported objects in Numexpr:
http://www.mail-archive.com/num...@li.../msg03146.html

There is still a case where unsupported objects can get into expressions
without Numexpr noticing.  For instance:

>>> import numexpr
>>> numexpr.evaluate('[]')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "numexpr/compiler.py", line 594, in evaluate
    _names_cache[expr_key] = getExprNames(ex, context)
  File "numexpr/compiler.py", line 570, in getExprNames
    ast = expressionToAST(ex)
  File "numexpr/compiler.py", line 84, in expressionToAST
    this_ast = ASTNode(ex.astType, ex.astKind, ex.value,
AttributeError: 'list' object has no attribute 'astType'

The attached patch makes the error clearer and more consistent with the
error added in the aforementioned thread:

>>> import numpy
>>> import numexpr
>>> numexpr.evaluate('[]')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "numexpr/compiler.py", line 596, in evaluate
    _names_cache[expr_key] = getExprNames(ex, context)
  File "numexpr/compiler.py", line 571, in getExprNames
    ex = stringToExpression(text, {}, context)
  File "numexpr/compiler.py", line 229, in stringToExpression
    raise TypeError("unsupported expression type: %s" % type(ex))
TypeError: unsupported expression type: <type 'list'>

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.)

::

	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       Cárabos Coop. V.  V  V   Enjoy Data
	                          ""

Re: [Numpy-discussion] More on Numexpr-unsupported objects

[Tim H. <tim...@ie...>]

Ivan Vilata i Balaguer wrote:


[SNIP]
>
> 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.

-tim