This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: RawArray does not accept long
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: Robert.Kern, jnoller, mark.dickinson, python-dev
Priority: normal Keywords: patch

Created on 2011-03-25 19:47 by Robert.Kern, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
raw-array-long.diff Robert.Kern, 2011-03-25 19:47 review
Messages (6)
msg132144 - (view) Author: Robert Kern (Robert.Kern) Date: 2011-03-25 19:47
The constructor for multiprocessing.RawArray() takes an argument that is either an integer size or a sequence to initialize the contents. To determine if the argument is a size, it uses isinstance(x, int). This means that integers that happen to be Python longs cause an error. On Win64 systems, Python ints are still 32-bits, so valid sizes for arrays sometimes must be represented by Python longs.

Attached is a patch that uses operator.index() to determine if the object can be used as an integer size.
msg132146 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2011-03-25 20:10
Thanks for the patch.

Are there practical cases where the operator.index check is more useful that the isinstance(..., (int, long)) check that you originally proposed (off-tracker)?  While I agree that it's the right fix in principle, the operator.index check smells a bit like new functionality to me, and risks changing behaviour for those (rare, I hope) user-defined classes that implement both __index__ and sequence methods.
msg132151 - (view) Author: Robert Kern (Robert.Kern) Date: 2011-03-25 20:44
The practical case I was thinking of was numpy integer scalar types, which can crop up without explicitly requesting them, much like the long type.

Although, now that I check, I see that single-element numpy arrays also pass index(). Ideally, there would be two functions, one that takes sizes and one that takes sequences, much like numpy has array() and empty().

I can revert my patch to doing the isinstance(x, (int, long)) test as a quick fix. That will allow most of the numpy scalar types that I expect will actually be encountered.
msg132164 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2011-03-25 21:59
> The practical case I was thinking of was numpy integer scalar types

Hmm, true.  But at least numpy.int instances pass an isinstance(..., int) check, right?  But that still leaves numpy.int<anything other than 32> as a problem on 32-bit systems and Windows, and similarly for 64-bit systems.

> Ideally, there would be two functions, [...]

Also true;  shame we can't fix this in 2.x.

I'll commit the isinstance(int, long) fix and your tests, since it's both safe and a clear improvement on the current behaviour.
msg132166 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-03-25 22:01
New changeset 2d183b1dae5a by Mark Dickinson in branch '2.7':
Issue #11673: Fix multiprocessing.[Raw]Array constructor to accept a size of type long.  Thanks Robert Kern.
http://hg.python.org/cpython/rev/2d183b1dae5a
msg132167 - (view) Author: Robert Kern (Robert.Kern) Date: 2011-03-25 22:08
numpy.int is just an alias to the builtin int, left for historical reasons. The integer scalar type that has the same width as Python's int (numpy.int32 or numpy.int64, depending) will always pass the isinstance() check. Since it's the default integer type in numpy arrays, it will be the most frequently encountered.

Thanks!
History
Date User Action Args
2022-04-11 14:57:15adminsetgithub: 55882
2011-03-26 10:28:00mark.dickinsonsetstatus: open -> closed
resolution: fixed
stage: commit review -> resolved
2011-03-25 22:08:27Robert.Kernsetmessages: + msg132167
2011-03-25 22:01:22python-devsetnosy: + python-dev
messages: + msg132166
2011-03-25 21:59:15mark.dickinsonsetmessages: + msg132164
2011-03-25 20:44:14Robert.Kernsetmessages: + msg132151
2011-03-25 20:18:18mark.dickinsonsetnosy: + jnoller
2011-03-25 20:13:46mark.dickinsonsetassignee: mark.dickinson
stage: commit review
2011-03-25 20:10:15mark.dickinsonsetnosy: + mark.dickinson
messages: + msg132146
2011-03-25 19:48:38mark.dickinsonlinkissue11672 superseder
2011-03-25 19:47:09Robert.Kerncreate