On Tue, Mar 6, 2012 at 1:44 PM, Robert Kern wrote:
> On Tue, Mar 6, 2012 at 18:25, Travis Oliphant wrote:
> > Why do we want to return a single string char instead of an int?
>
> I suspect just to ensure that any provided value fits in the range
> 0..255. But that's easily done explicitly.
>
Th
On Tue, Mar 6, 2012 at 1:25 PM, Travis Oliphant wrote:
> Why do we want to return a single string char instead of an int?
>
> There is a need for more flags on the dtype object. Using an actual
> attribute call seems like the way to go. This could even merge the contents
> of two struct membe
On Tue, Mar 6, 2012 at 18:25, Travis Oliphant wrote:
> Why do we want to return a single string char instead of an int?
I suspect just to ensure that any provided value fits in the range
0..255. But that's easily done explicitly.
--
Robert Kern
___
Nu
Why do we want to return a single string char instead of an int?
There is a need for more flags on the dtype object. Using an actual attribute
call seems like the way to go. This could even merge the contents of two
struct members so that we can add more flags but preserve ABI compatibility.
On Tue, Mar 6, 2012 at 6:20 AM, Robert Kern wrote:
> On Tue, Mar 6, 2012 at 03:53, David Cournapeau wrote:
>> Hi,
>>
>> This is following the discussion on bug
>> http://projects.scipy.org/numpy/ticket/2017
>>
>> Essentially, there is a discrepency between the actual type of the
>> flags member i
On Tue, Mar 6, 2012 at 03:53, David Cournapeau wrote:
> Hi,
>
> This is following the discussion on bug
> http://projects.scipy.org/numpy/ticket/2017
>
> Essentially, there is a discrepency between the actual type of the
> flags member in the dtype C structure (char) and how it is declared in
> th
Hi,
This is following the discussion on bug
http://projects.scipy.org/numpy/ticket/2017
Essentially, there is a discrepency between the actual type of the
flags member in the dtype C structure (char) and how it is declared in
the descriptor table (T_INT). The problem is that we are damned if we
f
