I have a different question about this than the rest of the thread. I'm confused at why there isn't a programmatic way to create a datetime dtype, other than by going through this special string-based mini-language. I guess I generally think of string-based dtype descriptors as being a legacy thing necessary for compatibility, but probably better to avoid in new code, now that we have nice python ways to describe dtypes with scalar types and such. Probably that's a minority opinion, but even putting it aside: it certainly isn't the case that we can describe arbitrary dtypes using strings right now - think of record types and so on. And even restricting ourselves to atomic styles, I'm skeptical about this claim that we'll be able to use strings for everything in the future, too. My pet possible future dtype is one for categorical data, which would be parametrized by the set of possible categories; I don't relish the idea of making up some ad hoc syntax for specifying such lists within the dtype mini-language.
So is the plan actually to promote strings as the canonical way of describing dtypes? Aside from the question of what repr does, shouldn't there actually be some sort of syntax like dtype=np.datetime64("D") available as a working option? - Nathaniel On Jul 27, 2011 10:55 AM, "Mark Wiebe" <mwwi...@gmail.com> wrote: > This was the most consistent way to deal with the parameterized dtype in the > repr, making it more future-proof at the same time. It was producing reprs > like "array(['2011-01-01'], dtype=datetime64[D])", which is clearly wrong, > and putting quotes around it makes it work in general for all possible > dtypes, present and future. > > -Mark > > On Wed, Jul 27, 2011 at 12:50 PM, Matthew Brett <matthew.br...@gmail.com >wrote: > >> Hi, >> >> I see that (current trunk): >> >> In [9]: np.ones((1,), dtype=bool) >> Out[9]: array([ True], dtype='bool') >> >> - whereas (1.5.1): >> >> In [2]: np.ones((1,), dtype=bool) >> Out[2]: array([ True], dtype=bool) >> >> That is breaking quite a few doctests. What is the reason for the >> change? Something to do with more planned dtypes? >> >> Thanks a lot, >> >> Matthew >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion