> I agree. I think we should recommend sane, descriptive names that do the
> right thing. So ideally we'd have people spell their dtype specifiers as
> dtype=bool # or np.bool
> dtype=np.float64
> dtype=np.int64
> dtype=np.complex128
> The names with underscores at the end make little sense from a UX
> perspective. And the C equivalents (single/double/etc) made sense 15 years
> ago, but with the user base of today - the majority of whom will not know C
> fluently or at all - also don't make too much sense.
>
> The `dtype=int` or `dtype=np.int_` behaviour flopping between 32 and 64 bits
> is likely to be a pitfall much more often than it is what the user actually
> needs, so shouldn't be recommended and probably deserves a warning in the
> docs.
I kinda disagree with this. I want to have a way to say, give me an array of
the same type as the default NumPy type (for either ints or floats). This will
prevent casting back and forth as different arrays are combined. In other
words, as long as NumPy itself flips back and forth (depending on locale), I
think users will in many cases want to flip back and forth with it?
Juan.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
