On 30 September 2011 21:50, Dag Sverre Seljebotn
<d.s.seljeb...@astro.uio.no> wrote:
> Note: The last field in a C struct can be of variable size, decided at
> malloc-time. I can't think of a clear syntax for that, except perhaps a
> builtin function cython.coercevariablesizestruct...
>
>
>
> Dag Sverre
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
That's really more of a hack right, not something that's technically
legal in C. If the user want to use hacked data structures, he/she
should not rely on built-in conversion, but convert manually, by
building a dict manually or whatever (and by casting like
<int[:variable_length]> mystruct.my_last_overallocated_field).
> mark florisson <markflorisso...@gmail.com> wrote:
>>
>> On 29 September 2011 22:48, Robert Bradshaw <rober...@math.washington.edu>
>> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson >
>> <markflorisso...@gmail.com> wrote: >> On 29 September 2011 13:13, Miguel
>> Angel <skud...@gmail.com> wrote: >>>> >>>> Structs already coerce to python
>> dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a
>> dict to a struct (you have to be >>>> careful with strings, making sure you
>> hold a reference to the string >>>> object as long as you use the pointer in
>> the struct). You have to be >>>> sure to declare every struct attribute
>> though. >>> >>> Could i see an example usage of this in any repository or
>> the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel.
>> >>> >> >> It's not in the documentation yet, I updated that in a branch that
>> >> still needs to be merged (which hopefully will be in 0.16). The >>
>> functionality from struct -> object is there though: >> >> cdef extern from
>> *: >> ctypedef struct MyStruct: >> int attrib >> >> cdef MyStruct
>> s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only
>> eats compile-time expressions here > > or even > > s =
>> MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict
>> assignment. > It would be natural to support array -> list conversion for
>> slices the > baseclass is convertable, e.g. > > cdef double* data = ... >
>> print data[:10] > > Converting an int[10] to a Python object without
>> slicing is a bit odd as > > cdef int a[10] > [compute a] > cdef
>> object o = a > a[0] = something else > o[1] = another thing > > is
>> non-initiative, as arrays can't be assigned in C and "assignment" > of lists
>> in Python are by reference, not by copy. "o = a[:]" is plenty > clear that
>> there's a copy, so that's better. The other way is a bit > messier, but > >
>> a[:n] = [python list] > > could certainly be supported via an implicit
>> loop. Another > consideration is that with primitive data types we're
>> venturing into > memory view territory, which might be a more useful
>> representation > than Python lists. > > - Robert > Indeed. Currently you can
>> only cast pointers to memoryview slices, but there's no reason to not
>> support arrays as well (without also needing to first cast the array to a
>> pointer). So if arrays have shape information, you could immediately coerce
>> to memoryview (cython.array) objects without needing a cast. This would also
>> work for arrays in structs, as they can only ever have a static size (known
>> at C compile time). Shall we support that? I won't be hard as the
>> infrastructure for casting pointers is already there.
>> ________________________________
>> cython-devel mailing list cython-devel@python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>
> _______________________________________________
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
