![](https://secure.gravatar.com/avatar/5b2449484c19f8e037c5d9c71e429508.jpg?s=120&d=mm&r=g)
On 7/7/07, Travis Oliphant <oliphant.travis@ieee.org> wrote:
On 7/6/07, *Travis Oliphant* <oliphant.travis@ieee.org <mailto:oliphant.travis@ieee.org>> wrote:
Timothy Hochberg wrote: > > I'm working on getting some old code working with numpy and I noticed > that bool_ is not a subclass of int. Given that python's bool > subclasses into and that the other scalar types are subclasses of > their respective counterparts it seems at first glance that > numpy.bool_ should subclass python's bool, which in turn
subclasses
> int. Or am I missing something here? The reason it is not, is because it is not binary compatible with Python's integer. The numpy bool_ is always only 8-bits while the Python integer is 32-bits or 64-bits.
This could be changed I suspect, but then it would break the relationship between scalars and their array counterparts
Do you have and idea off the top of your head head how painful this would be from an implementation standpoint. And is there a theoretical reason that it is important that the scalar and array implementations match? I would think that, conceptually, they are all 1-bit integers, and it seems that the 8-bit, versus 32- or 64-bits is just an implementation detail.
It would probably take about 2-3 hours to make the change and about 3 more hours to fix the problems that were not anticipated. Basically, we would have to special-case the bool like we do the unicode scalar (which also doesn't necessarily match the array-based representation but instead follows the Python implementation).
I guess I don't really see a problem in switching just the numpy.bool_ scalar to be a sub-class of the Python bool type and adjusting the code to make the switch when creating a scalar.
Thanks for info. I'll put this on my list of things to look into, although it may take me a few weeks to get around to it, depending on how busy next week is. I don't see this as urgent, but it seems like a good change to make going forward. -- . __ . |-\ . . tim.hochberg@ieee.org