Hmm, I sent it to only Hugo again. Time to check my mail client settings...
>
>> I understand the need and semantics for changing the handling of arrays
>> for function arguments. However, I am not trying to change the behavior
>> for a function argument in this case. I am trying to access a member (or
>> class static) variable that happens to be an array. The example I gave
>> is roughly as follows:
>>
>> class Foo
>> {
>> public:
>> // constructor, other methods, etc.
>> size_t scalar;
>> size_t array[2];
>> }
>>
>> As you suggested, adding a primitive-type tag like this:
>>
>> <primitive-type name="size_t" default-constructor="0"
>> target-lang-api-name="PyLong" />
>>
>>
>> works great for the member variable "scalar" above. It does not handle
>> the member variable "array" above. It really can just become either a
>> Python tuple or a list, with a slight preference for a tuple in the case
>> of a static const class variable that happens to be an array.
>>
>> Have I missed something?
>>
> Oh, sorry now I see, it's a public attribute of your class, you are right
> there's no special semantics in this case, is clear what should be exported
> to
> Python.
>
Well, that's too bad. I was hoping I missed something obvious (not
really because that would mean I asked a redundant question).
> But there are some problems...
>
> We can't export if as a tuple because tuples are immutable objects in Python,
> so we need to export this attribute as a list, however we need to forbidden
> the user to do some constructs like:
>
As I noted, in the actual library I am writing bindings for, the
variable is a constant static class variable, so the immutable nature of
a tuple would be perfect for that application. In other words, for a C++
class like this:
class FooStatic
{
public:
static const size_t array[2];
}
I believe a tuple of size 2 would be a logical mapping between the two.
However, that is not how I posed the problem to the mailing list.
> foo = Foo()
> foo.array.append(2);
>
> Because the size of array must be constant.
>
Good point.
> There is another problem regarding to the sync between Python and C++, if the
> user do:
>
> foo.array[0] = 3
>
> The array gets modified by him, ok, but how C++ will knows that the list was
> modified? C++ need to knows it to proper copy the values back to the C++ Foo
> instance that lies behind the Pyhton object.
>
Well, knowledge of the modification to the values in the array is also a
problem in C++ unless I am mistaken. I would think that if tracking the
changes was desirable, one would use a more sophisticated class than a
plain array of size_t values. Your next paragraph tells me that perhaps
I do not yet fully grasp what you are talking about.
> The problem is that the Python list is another thing, different from the C++
> array and we can't tell the Python list to point to the C++ address of
> Foo.array, so we need to copy some data to Python but we never know when to
> copy this values back to C++.
>
> However I think all these problems could be addressed if we create a new
> object to deal with this, this object would hold a pointer to the C++ array
> it's mapping and direct change it when necessary, but this rises a new set of
> minor problems, e.g. we would need different objects for different C++ types,
> etc..
>
That sounds like a template class just waiting to happen to me. If you
can point me in the right direction, I can take a swing at it, although
I'll warn you that I am CPython novice at best.
Thanks
John Cummings
_______________________________________________
PySide mailing list
[email protected]
http://lists.pyside.org/listinfo/pyside
