Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

numpy.dtype('float64') == None returns True (Trac #1594) #2190

Open
numpy-gitbot opened this Issue Oct 19, 2012 · 7 comments

Comments

Projects
None yet
3 participants

numpy-gitbot commented Oct 19, 2012 edited by eric-wieser

Original ticket http://projects.scipy.org/numpy/ticket/1594 on 2010-08-26 by trac user Zbyszek_Szmek, assigned to unknown.

Automatic dtype conversion is performed when dtype object is compared with something of different class. A special case is that None is converted to the default dtype.

This result in surprising behavior when comparing with None:

>>> numpy.dtype('float64') == None
True
>>> numpy.dtype('float32') == None
False

This behaviour is present in numpy at least 1.3.0 - 1.5.0.

trac user Zbyszek_Szmek wrote on 2010-08-26

From numpy-discussion...

On Wed, Aug 25, 2010 at 12:41:37PM -0500, Travis Oliphant wrote:

On Aug 23, 2010, at 11:55 AM, Zbyszek Szmek wrote:

On Mon, Aug 23, 2010 at 06:50:09PM +0200, Tiziano Zito wrote:

hi all,
we just noticed the following weird thing:

$ python
Python 2.6.6rc2 (r266rc2:84114, Aug 18 2010, 07:33:44)
[GCC 4.4.5 20100816 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

import numpy
numpy.version.version
'2.0.0.dev8469'
Also with numpy.version.version == 1.3.0.

This certainly looks odd. If you can file a bug-report that would be great.

arraydescr_richcompare calls PyArray_DescrConverter, which converts None
to PyArray_DEFAULT...

/*NUMPY_API

  • Get typenum from an object -- None goes to PyArray_DEFAULT
  • This function takes a Python object representing a type and converts it
  • to a the correct PyArray_Descr * structure to describe the type.
  • Many objects can be used to represent a data-type which in NumPy is
  • quite a flexible concept.
  • This is the central code that converts Python objects to
  • Type-descriptor objects that are used throughout numpy.
  • new reference in _at
    */
    NPY_NO_EXPORT int
    PyArray_DescrConverter(PyObject *obj, PyArray_Descr *_at)

So:

numpy.dtype('float32') == '<f4'
True
numpy.dtype('float32') == 'float64'
False
numpy.dtype('float32') == 'float32'
True
numpy.dtype('float32') == 'float33'
Traceback (most recent call last):
File "", line 1, in
TypeError: data type not understood

I think that this automatic conversion is pretty dangerous, especially in case
of None.

Milestone changed to Unscheduled by trac user Zbyszek_Szmek on 2010-08-26

Owner

charris commented Feb 20, 2014

There are several tickets along this line. I don't know that there is much to be done at this point as the real problem is the == operator of dtype and changing that would probably break a ton of code. I suppose we could deprecate it and only do comparisons between dtype objects.

Owner

njsmith commented Feb 20, 2014

I can't imagine anyone would object if we made it so dtype comparisons only
worked against things that could be passed to the dtype() constructor.
(After deprecation.)
On 19 Feb 2014 20:36, "Charles Harris" notifications@github.com wrote:

There are several tickets along this line. I don't know that there is much
to be done at this point as the real problem is the == operator of dtype
and changing that would probably break a ton of code. I suppose we could
deprecate it and only do comparisons between dtype objects.


Reply to this email directly or view it on GitHubhttps://github.com/numpy/numpy/issues/2190#issuecomment-35575833
.

Owner

charris commented Feb 20, 2014

Well, there is

In [47]: dtype(None)
Out[47]: dtype('float64')

But

In [48]: dtype(10)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-48-76aac0629e5b> in <module>()
----> 1 dtype(10)

TypeError: data type not understood

So I think that is already the case.

Owner

njsmith commented Feb 20, 2014

Oh, well, we could probably deprecate dtype(None), which seems pretty
useless, but I don't know if it's worth the bother...
On 19 Feb 2014 20:53, "Charles Harris" notifications@github.com wrote:

Well, there is

In [47]: dtype(None)
Out[47]: dtype('float64')

But

In [48]: dtype(10)

TypeError Traceback (most recent call last)
in ()
----> 1 dtype(10)

TypeError: data type not understood

So I think that is already the case.


Reply to this email directly or view it on GitHubhttps://github.com/numpy/numpy/issues/2190#issuecomment-35576788
.

Owner

charris commented Feb 20, 2014

+1 for that. If you open an issue there is a Deprecation label.

rnikutta added a commit to rnikutta/hypercubizer that referenced this issue Aug 27, 2017

HDF5 storage now stores ragged arrays natively, since h5py has an own
workaround for bug numpy/numpy#2190 i.e. we don't need the PadArray
wrapper anymore.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment