I took a look into the code to see what is causing this, and the reason is that nothing has ever been implemented to deal with the fields. This means it falls back to treating all struct dtypes as if they were a plain "void" dtype, which allows anything to be cast to it.
While I was redoing the casting subsystem for 1.6, I did think on this issue, and decided that it wasn't worth tackling it at the time because the 'safe'/'same_kind'/'unsafe' don't seem sufficient to handle what might be desired. I tried to leave this alone as much as possible. Some random thoughts about this are: * Casting a scalar to a struct dtype: should it be safe if the scalar can be safely cast to each member of the struct dtype? This is the NumPy broadcasting rule applied to dtypes as if the struct dtype is another dimension. * Casting one struct dtype to another: If the fields of the source are a subset of the target, and the types can safely convert, should that be a safe cast? If the fields of the source are not a subset of the target, should that still be a same_kind cast? Should a second enum which complements the safe/same_kind/unsafe one, but is specific for how adding/removing struct fields be added? This is closely related to adding ufunc support for struct dtypes, and the choices here should probably be decided at the same time as designing how the ufuncs should work. -Mark On Mon, Feb 13, 2012 at 5:20 PM, Matthew Brett <[email protected]>wrote: > Hi, > > I've also just noticed this oddity: > > In [17]: np.can_cast('c', 'u1') > Out[17]: False > > OK so far, but... > > In [18]: np.can_cast('c', [('f1', 'u1')]) > Out[18]: True > > In [19]: np.can_cast('c', [('f1', 'u1')], 'safe') > Out[19]: True > > In [20]: np.can_cast(np.ones(10, dtype='c'), [('f1', 'u1')]) > Out[20]: True > > I think this must be a bug. > > In the other direction, it makes more sense to me: > > In [24]: np.can_cast([('f1', 'u1')], 'c') > Out[24]: False > > In [25]: np.can_cast([('f1', 'u1')], [('f1', 'u1')]) > Out[25]: True > > Best, > > Matthew > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
