From: Konrad H. <hi...@cn...> - 2002-06-11 12:56:26
|
Travis Oliphant <oli...@ie...> writes: > Actually, the code in PyArg_ParseTuple asks the object it gets if it > knows how to be a float. 0-d arrays for some time have known how to be > Python floats. So, I do not think this error occurs as you've > described. Could you demonstrate this error? No, it seems gone indeed. I remember a lengthy battle due to this problem, but that was a long time ago. > The only exception to this that I've seen is the list indexing code > (probably for optimization purposes). There could be more places, but > I have not found them or heard of them. Even for indexing, I don't see the point. If you test for the int type and do conversion attempts only for non-ints, that shouldn't slow down normal usage at all. > have now. I'm quite supportive of never returning Python scalars from > Numeric array operations unless specifically requested (e.g. the > toscalar method). I suppose this would be easy to implement, right? Then why not do it in a test release and find out empirically how much code it breaks. > presumption based? If I encounter a Python object that I'm unfamiliar > with, I don't presume to know how it will define multiplication. But if that object pretends to be a number type, a sequence type, a mapping type, etc., I do make assumptions about its behaviour. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- |