RE: [Numpy-user] possible error with isarrtype
![](https://secure.gravatar.com/avatar/f3e9722c4d131e70113935289568a972.jpg?s=120&d=mm&r=g)
Thanks Travis. With regard to what to do with the functions, I only ended up trying them because they were there. From my point of view, I'd love to learn how to code the "right" way. To that end, any means of informing the user of "deprecated" functions (or just taking them out) would be fine with me. However, I realize some may have legacy code and so I would defer to their opinions.
What use were you making of them?
I was just migrating some working scipy/numeric code I'd been using to the newer numpy (0.9.4), python (2.4.2), and scipy (0.4.4). When I ran my unit-tests, one line that gave me problems was: import scipy as sp ... assert( type(deltaTime_sec)==float ) This line of code was there to inform me if I was accidentally passing in an array type instead of a scalar. This no longer worked in the new environment. The type of deltaTime_sec came out as float64_arrtype which did not equal type float causing the assertion to trip which I believe to be caused by the following:
I ended up fixing it with the following code which seems to do the trick (though I'm always keen to learn better ways of doing things): assert( sp.size(deltaTime_sec)==1 ) Thanks! Michael
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
O'Keefe, Michael wrote:
Ah... This is something that needs to be added to the FAQ, because it is common. Basically, you should almost never test for type equality like this since with >Python2.2 the Python float can be inherited from (that's what a float64scalar does --- used to be called float64_arrtype). So, instead you should use assert (isinstance(deltaTime_sec, float)) which would still work with the new float scalar objects. The big advantage of the new scalar types and objects is that there is a 1-1 relationship between the scalar types and the basic array data-types and the new scalars have all the methods and attributes of arrays. So, in fact you could write: assert(deltaTime_sec.size == 1) and this would work whether deltaTime is a scalar or an array with only one element. -Travis
![](https://secure.gravatar.com/avatar/5a7d8a4d756bb1f1b2ea729a7e5dcbce.jpg?s=120&d=mm&r=g)
O'Keefe, Michael wrote:
Python has a proper framework for deprecation warnings. I'd say we use that, and Travis can ruthlessly deprecate anything that's just compatibility noise. Perhaps 1.0 can keep old but deprecated things around (numpy will see a LOT of use once 1.0 comes out, far more than the current svn testing crowd). Then, as of 1.1 or 1.2 or whatever, those can be removed. Cheers, f
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Colin J. Williams wrote:
One of the deprecated names is ArrayType. This seems to be closer to the Python style than ndarray.
Not really. Rather than test: type(var) == types.IntType you should be testing isinstance(var, int) just like rather than testing type(somearray) == ArrayType you should be testing isinstance(somearray, ndarray) Python style has changed a bit since 2.2 allowed sub-typing builtings -Travis
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
[Dbg]>>> import types [Dbg]>>> dir(types) ['BooleanType', 'BufferType', 'BuiltinFunctionType', 'BuiltinMethodType', 'ClassType', 'CodeType', 'ComplexType', 'DictProxyType', 'DictType', 'DictionaryType', 'EllipsisType', 'FileType', 'FloatType', 'FrameType', 'FunctionType', 'GeneratorType', 'Instance Type', 'IntType', 'LambdaType', 'ListType', 'LongType', 'MethodType', 'ModuleType', 'NoneType', 'NotImplementedType', 'ObjectType', 'SliceType', 'StringType', 'StringTypes', 'TracebackType', 'TupleType', 'TypeType', 'UnboundMethodType', 'UnicodeType', 'XRan geType', '__builtins__', '__doc__', '__file__', '__name__'] [Dbg]>>> I presume that the aim is still that numpy will become a part of the Python offering. Colin W.
![](https://secure.gravatar.com/avatar/8185be81060345a47ca63640f135529c.jpg?s=120&d=mm&r=g)
On Wed, 01 Feb 2006 11:15:09 -0500 "Colin J. Williams" <cjw@sympatico.ca> wrote: [ depration + style ]
Isn't the types module becoming superfluous? [packer@zombie ~]$ python -E Python 2.4 (#2, Feb 12 2005, 00:29:46) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Gerard
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
I was simply trying to suggest that the name ArrayType is more appropriate name that ndbigarray or ndarray for the multidimensional array. Since the intent is, in the long run, to integrate numpy with the Python distribution, the use of a name in the style of the existing Python types would appear to be better. Is the types module becoming superfluous? I've cross posted to c.l.p to seek information on this. Colin W.
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
O'Keefe, Michael wrote:
Ah... This is something that needs to be added to the FAQ, because it is common. Basically, you should almost never test for type equality like this since with >Python2.2 the Python float can be inherited from (that's what a float64scalar does --- used to be called float64_arrtype). So, instead you should use assert (isinstance(deltaTime_sec, float)) which would still work with the new float scalar objects. The big advantage of the new scalar types and objects is that there is a 1-1 relationship between the scalar types and the basic array data-types and the new scalars have all the methods and attributes of arrays. So, in fact you could write: assert(deltaTime_sec.size == 1) and this would work whether deltaTime is a scalar or an array with only one element. -Travis
![](https://secure.gravatar.com/avatar/5a7d8a4d756bb1f1b2ea729a7e5dcbce.jpg?s=120&d=mm&r=g)
O'Keefe, Michael wrote:
Python has a proper framework for deprecation warnings. I'd say we use that, and Travis can ruthlessly deprecate anything that's just compatibility noise. Perhaps 1.0 can keep old but deprecated things around (numpy will see a LOT of use once 1.0 comes out, far more than the current svn testing crowd). Then, as of 1.1 or 1.2 or whatever, those can be removed. Cheers, f
![](https://secure.gravatar.com/avatar/49df8cd4b1b6056c727778925f86147a.jpg?s=120&d=mm&r=g)
Colin J. Williams wrote:
One of the deprecated names is ArrayType. This seems to be closer to the Python style than ndarray.
Not really. Rather than test: type(var) == types.IntType you should be testing isinstance(var, int) just like rather than testing type(somearray) == ArrayType you should be testing isinstance(somearray, ndarray) Python style has changed a bit since 2.2 allowed sub-typing builtings -Travis
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
[Dbg]>>> import types [Dbg]>>> dir(types) ['BooleanType', 'BufferType', 'BuiltinFunctionType', 'BuiltinMethodType', 'ClassType', 'CodeType', 'ComplexType', 'DictProxyType', 'DictType', 'DictionaryType', 'EllipsisType', 'FileType', 'FloatType', 'FrameType', 'FunctionType', 'GeneratorType', 'Instance Type', 'IntType', 'LambdaType', 'ListType', 'LongType', 'MethodType', 'ModuleType', 'NoneType', 'NotImplementedType', 'ObjectType', 'SliceType', 'StringType', 'StringTypes', 'TracebackType', 'TupleType', 'TypeType', 'UnboundMethodType', 'UnicodeType', 'XRan geType', '__builtins__', '__doc__', '__file__', '__name__'] [Dbg]>>> I presume that the aim is still that numpy will become a part of the Python offering. Colin W.
![](https://secure.gravatar.com/avatar/8185be81060345a47ca63640f135529c.jpg?s=120&d=mm&r=g)
On Wed, 01 Feb 2006 11:15:09 -0500 "Colin J. Williams" <cjw@sympatico.ca> wrote: [ depration + style ]
Isn't the types module becoming superfluous? [packer@zombie ~]$ python -E Python 2.4 (#2, Feb 12 2005, 00:29:46) [GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
Gerard
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
I was simply trying to suggest that the name ArrayType is more appropriate name that ndbigarray or ndarray for the multidimensional array. Since the intent is, in the long run, to integrate numpy with the Python distribution, the use of a name in the style of the existing Python types would appear to be better. Is the types module becoming superfluous? I've cross posted to c.l.p to seek information on this. Colin W.
participants (6)
-
Colin J. Williams
-
Fernando Perez
-
Gerard Vermeulen
-
O'Keefe, Michael
-
Travis Oliphant
-
Travis Oliphant