Giovanni Bajo wrote: > Another workaround could be: > > return scipy.where( > "xsum != n or psum < 0.99999 or " > "psum > 1.000001 or not scipy.isfinite(result)", > -scipy.inf, result) > > with the necessary magic to pull out variables from the stack frame. Parsing > could be done only once of course. But I'm sure the numpy guys have already > thought and discarded this solution as it's more complicated.
Well, it doesn't actually solve the problem. Yes, we could write functions that parse some language that looks like Python but executes as something else, but that doesn't advance us towards the goal of making the code easier to understand. > [[ In fact, numpy is actually trying to create a DSL with Python itself. It isn't. At least, not any more than any other custom type is. > I > assume things like "x.sum(-1)" would have been probably spelled sum(x, -1), > if > you could freely decide what to do without worrying about the > implementation. ]] In fact, it can be spelled so and once could only be spelled so in Numeric. > Or, another workaround is something like this: > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/384122, which could > probably be extended to more "operators" that numpy can't simulate using the > plain Python syntax. Much as we'd like it to be, it's just not practical. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
