Hi, On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe <mwwi...@gmail.com> wrote: > 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.
Thanks for the discussion - that's very helpful. How about, at a first pass, returning True for conversion of void types only if input dtype == output dtype, then adding more sophisticated rules later? See you, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion