On May 27, 2010, at 1:08 AM, Dag Sverre Seljebotn wrote: > Robert Bradshaw wrote: >> On May 27, 2010, at 12:43 AM, Dag Sverre Seljebotn wrote: >> >> >>> I recognized typeof in a recent commit by Robert. Is this a new >>> feature >>> in 0.13 or has it been in for some time? >>> >> >> It's been around since last fall--I just needed something quick for >> writing tests for type inference, so typeof was born. >> > OK, then this doesn't need to be discussed now at any rate. > > I'll just make a quick comment below and then hope the thread dies. >> >>> If it is new: >>> >>> What I'm wondering is whether typeof should perhaps, in the spirit >>> of >>> Python, return a descriptive object instead of a string. (It could >>> even >>> return a ctypes object describing the type, if that is powerful >>> enough >>> for us). >>> >>> In particular, it should be possible to do introspection about >>> structs >>> and so on, so that it is easy to build serializers etc. using >>> "typeof" >>> information. (Buffers already put some RTTI about structs to the C >>> file >>> BTW, in order to parse buffer format strings.) >>> >>> This is thinking long-term; but I'm wondering whether the current >>> typeof >>> should be renamed e.g. "nameoftype", in order to maintain backwards >>> compatability if or when somebody decides to make a more powerful >>> typeof. >>> >> >> I was thinking of that at first, but I really can't think of much one >> would do with it--it's not giving anything that's not known at >> compile >> time, it's just a way to make sure the compiler thinks the type is >> what you think it is. Even with templates, it would return the >> template parameter, not the resolved type. For testing purposes, a >> string is very nice. >> > cdef persist_struct_to_xml(void* data, object typeinfo, object > filename): ... > > cdef StructA a > a.b = 2 > a.c = 4 > persist_struct_to_xml(&a, typeof(StructA), 'a.dat') > > cdef StructB b > b.foo = 2 > b.bar = 4.5 > persist_struct_to_xml(&b, typeof(StructB), 'b.dat') > > Basically, the type information for structs should be a tree, > containing > names and *offsets* and types. persist_struct_to_xml needs to have > special-case if-tests on all the primitive types, but structs can be > dealt with through pointer manipulation and offsets. > > Offsets can trivially be resolved by the C compiler during C > compilation > and put into the type information then (in fact, I already do in the > buffer RTTI, which is used for validating buffer data format strings). > > Of course, it's just a convenience, but if you need this, a very big > one.
Ah, that is a nice use case. As Stefan mentioned, plain old type will (someday) probably work well here. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
