[Cython] [cython-users] Re: callback function pointer problem

[mark florisson]

On 30 September 2011 22:42, mark florisson <markflorisson88 at gmail.com> wrote:
> On 30 September 2011 22:14, Dag Sverre Seljebotn
> <d.s.seljebotn at astro.uio.no> wrote:
>> Are you saying that when coercing a struct to an object, one would copy
>> scalar fields by value but reference array fields? -1, that would be
>> confusing. Either the whole struct through a view, or copy it all.
>
> Hmm, yeah it might be confusing. To me it makes sense though, as
> scalars are immutable but arrays are not, although by that logic the
> struct should be a view. So perhaps a list makes more sense. Making
> arrays in structs lists means you likely want to do the same for the
> normal case, i.e. arrays as variables. I'm not sure you'd want normal
> arrays to object conversion to be implicit though, I'd rather see an
> explicit cast for that.

I suppose none of it makes me very happy, maybe I'll just forget about
it for now.

>> It bothers me that structs are passed by value in Cython, but it seems
>> impossible to change that now. (i.e, once upon a time one could have
>> required the use of a copy method to do a struct assignment and give a
>> syntax error otherwise, which would have worked nicer with Python
>> semantics).
>>
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> mark florisson <markflorisson88 at gmail.com> wrote:
>>>
>>> On 29 September 2011 22:48, Robert Bradshaw <robertwb at math.washington.edu>
>>> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson >
>>> <markflorisson88 at gmail.com> wrote: >> On 29 September 2011 13:13, Miguel
>>> Angel <skuda21 at 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 at python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>>
>