Dag Sverre Seljebotn wrote:
> Hoyt Koepke wrote:
>> Out of curiosity, how difficult would it be to implement a new
>> container type that emulates python's list but only holds one time and
>> would work with both PyObject* and c types? Say vector[type] to
>> distinguish it from list. Here would be my wishlist, given my current
>> use cases, in order of desirability.
>
> I don't think such a type should be built into Cython itself, but should
> be written as just another class in pyx and pxd files (which can be
> shipped with Cython perhaps).
Agreed.
> However, it seems to require templates/generics in Cython. So that would
> be the place to start working. Unfortunately that would probably be some
> work (on the order of a GSoC I think?), but I think that would be a much
> better approach than hard-coding in a brand new vector type in Cython.
>
> (This is when I usually state that I think it is better if we can properly
> wrap STL though, which will hopefully be done something about in summer,
> since the list of data structures which it would be nice to have doesn't
> at all stop with vectors.)
Wrapping the STL sounds like a different feature. I don't think we should
*require* C++ here. Writing type templates into plain C would be a lot more
useful. It would be more work, sure, but it shouldn't be too hard. It would
mainly require smarter type checks (i.e. MyType<double> != MyType<int>) and
code duplication in the generated C code. Maybe it's not even that hard to
hack that into the current code.
Imagine you could write
cdef class MyType<T>(object):
# type T gets defined in the class scope to make the parser happy
cdef T* my_attribute
def __init__(self, T value):
self.my_attribute = malloc(sizeof(T)*1000)
self.my_attribute[100] = value
def T do_work(self, T input):
return input + self.my_attribute[100]
o = MyType<int>(20) # first occurrence creates/registers the type
o.do_work(18)
ctypedef MyType<int> MyIntType # reuses the type and provides a name
cdef MyIntType ot = MyIntType(25)
print ot.do_work(19)
ctypedef MyType<double> MyDType # creates and defines a new type
I'm not sure if a common base class would make sense here, something that
would just implement everything that doesn't depend on T. But maybe that's
overkill already. And most stuff *will*
We might be able to implement this completely textually, i.e. the parser
would declare the specialised types on the fly (as it does now for a
ctypedef or extension type, i.e. new C type names). The resulting types
would really be named "MyType<int>" internally, and we'd just do some name
mangling on the way out. It would just be about as 'powerful' as Java's
compile-time generics (minus being limited to types), and not more. That
doesn't sound like a GSoC to me.
Even template functions would be out of scope at the beginning (as they
would require knowing the type of a value/name that you pass, which isn't
available at parse time, i.e. doesn't fit the current type declaration scheme).
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
