[Numpy-discussion] some typestrings not recognized anymore
Nathaniel Smith
njs@pobox....
Sun Jun 3 09:49:58 CDT 2012
On Sun, Jun 3, 2012 at 3:28 PM, Ralf Gommers
<ralf.gommers@googlemail.com> wrote:
> Hi,
>
> Just ran into this:
>
>>>> np.__version__
> '1.5.1'
>>>> np.empty((1,), dtype='>h2') # works in 1.6.2 too
> array([0], dtype=int16)
>
>>>> np.__version__
> '1.7.0.dev-fd78546'
>>>> np.empty((1,), dtype='>h2')
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: data type ">h2" not understood
For reference the problem seems to be that in 1.6 and earlier, "h"
plus a number was allowed, and the number was ignored:
>>> np.__version__
'1.5.1'
>>> np.dtype("h2")
dtype('int16')
>>> np.dtype("h4")
dtype('int16')
>>> np.dtype("h100")
dtype('int16')
In current master, the number is disallowed -- all of those give
TypeErrors. Presumably because "h" already means the same as "i2", so
adding a second number on their is weird.
Other typecodes with an "intrinsic size" seem to have the same problem
-- "q", "l", etc.
Obviously "h2" should be allowed in 1.7, seeing as disallowing it
breaks scipy. And the behavior for "h100" is clearly broken and should
be disallowed in the long run. So I guess we need to do two things:
1) Re-enable the use of typecode + size specifier even in cases where
the typcode has an intrinsic size
2) Issue a deprecation warning for cases where the intrinsic size and
the specified size don't match (like "h100"), and then turn that into
an error in 1.8.
Does that sound correct? I guess the other option would be to
deprecate *all* use of size specifiers with these typecodes (i.e.,
deprecate "h2" as well, where the size specifier is merely redundant),
but I'm not sure removing that feature is really worth it.
-- Nathaniel
More information about the NumPy-Discussion
mailing list