Expected errors of tests/errors/cdef_members_T517.pxd
I'm splitting Symtab visibilities into explicit C and Python visibilities, but am having trouble reproducing the expected error messages for cdef_members_T517: $ python runtests.py cdef_members_T517 Python 2.6.6 (r266:84292, Dec 8 2010, 09:53:33) [GCC 4.4.4] Running tests against Cython 0.14.1+ === Expected errors: === 5:24: C attribute of type 'VoidP' cannot be accessed from Python 5:24: Cannot convert 'VoidP' to Python object 6:24: C attribute of type 'VoidP' cannot be accessed from Python 6:24: Cannot convert 'VoidP' to Python object 6:24: Cannot convert Python object to 'VoidP' 14:22: C attribute of type 'Foo' cannot be accessed from Python 14:22: Cannot convert Python object to 'Foo' === Got errors: === 5:24: C attribute of type 'VoidP' cannot be accessed from Python 5:24: Cannot convert 'VoidP' to Python object 6:24: C attribute of type 'VoidP' cannot be accessed from Python 6:24: Cannot convert 'VoidP' to Python object 6:24: Cannot convert Python object to 'VoidP' 14:22: Cannot convert Python object to 'Foo' So my code is not raising: 14:22: C attribute of type 'Foo' cannot be accessed from Python The relevant lines from tests/errors/cdef_members_T517.pxd are: $ grep -n ^ tests/errors/cdef_members_T517.pyx ... 8:ctypedef struct Foo: 9: int i 10: 11:cdef class Bar: 12: cdef Foo foo0 13: cdef readonly Foo foo2 14: cdef public Foo foo1 15: pass ... I see two options: 1) Foo attributes are readable from Python, in which case the expected errors should be changed to match mine. 2) Foo attributes are not readable from Python, in which case the expected errors should be extended with 13:22: C attribute of type 'Foo' cannot be accessed from Python and probably also also 14:22: Cannot convert 'Foo' to Python object I think (2) is more reasonable, until I get my public Python enums, stucts, and unions branch working, after which it would switch to (1) if the Foo struct was declared with readonly (vs. private) Python visibility. You can't alter the struct definition from Python, so a public Python visibility doesn't really make sense for the struct itself. -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
On Sat, Feb 26, 2011 at 5:08 AM, W. Trevor King <wking@drexel.edu> wrote:
I'm splitting Symtab visibilities into explicit C and Python visibilities, but am having trouble reproducing the expected error messages for cdef_members_T517:
$ python runtests.py cdef_members_T517 Python 2.6.6 (r266:84292, Dec 8 2010, 09:53:33) [GCC 4.4.4]
Running tests against Cython 0.14.1+
=== Expected errors: === 5:24: C attribute of type 'VoidP' cannot be accessed from Python 5:24: Cannot convert 'VoidP' to Python object 6:24: C attribute of type 'VoidP' cannot be accessed from Python 6:24: Cannot convert 'VoidP' to Python object 6:24: Cannot convert Python object to 'VoidP' 14:22: C attribute of type 'Foo' cannot be accessed from Python 14:22: Cannot convert Python object to 'Foo'
=== Got errors: === 5:24: C attribute of type 'VoidP' cannot be accessed from Python 5:24: Cannot convert 'VoidP' to Python object 6:24: C attribute of type 'VoidP' cannot be accessed from Python 6:24: Cannot convert 'VoidP' to Python object 6:24: Cannot convert Python object to 'VoidP' 14:22: Cannot convert Python object to 'Foo'
So my code is not raising:
14:22: C attribute of type 'Foo' cannot be accessed from Python
The relevant lines from tests/errors/cdef_members_T517.pxd are:
$ grep -n ^ tests/errors/cdef_members_T517.pyx ... 8:ctypedef struct Foo: 9: int i 10: 11:cdef class Bar: 12: cdef Foo foo0 13: cdef readonly Foo foo2 14: cdef public Foo foo1 15: pass ...
I see two options:
1) Foo attributes are readable from Python, in which case the expected errors should be changed to match mine.
Foo attributes are readable from Python, it converts the struct to a tuple.
2) Foo attributes are not readable from Python, in which case the expected errors should be extended with
13:22: C attribute of type 'Foo' cannot be accessed from Python
and probably also also
14:22: Cannot convert 'Foo' to Python object
I think (2) is more reasonable, until I get my public Python enums, stucts, and unions branch working, after which it would switch to (1) if the Foo struct was declared with readonly (vs. private) Python visibility. You can't alter the struct definition from Python, so a public Python visibility doesn't really make sense for the struct itself.
The visibility refers to the assignability of the member from Python, which makes total sense if there is a object -> Foo conversion. I thought I had implemented this, but I guess now. Once we have wrapping classes this makes total sense, so one can do b = Bar() b.foo1 = Foo(i=100) What's less clear is the behavior of b = Bar() b.foo1 = Foo(i=1) b.foo1.i = 100 print b.foo1 saved = b.foo1 del b print saved - Robert
On Sat, Feb 26, 2011 at 10:15:38AM -0800, Robert Bradshaw wrote:
On Sat, Feb 26, 2011 at 5:08 AM, W. Trevor King <wking@drexel.edu> wrote:
The relevant lines from tests/errors/cdef_members_T517.pxd are:
$ grep -n ^ tests/errors/cdef_members_T517.pyx ... 8:ctypedef struct Foo: 9: int i 10: 11:cdef class Bar: 12: cdef Foo foo0 13: cdef readonly Foo foo2 14: cdef public Foo foo1 15: pass ...
...
What's less clear is the behavior of
b = Bar() b.foo1 = Foo(i=1) b.foo1.i = 100 print b.foo1 saved = b.foo1 del b print saved
Is the problem choosing between: 1) Copy struct data into its own PyObject and let Python manage the memory. 2) Pass around a pointer to Cython-managed struct data. I suppose I don't really know enough about how Cython handles this yet to really see the problem or be able to help with a solution ;). -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
On Sat, Feb 26, 2011 at 6:34 PM, W. Trevor King <wking@drexel.edu> wrote:
On Sat, Feb 26, 2011 at 10:15:38AM -0800, Robert Bradshaw wrote:
On Sat, Feb 26, 2011 at 5:08 AM, W. Trevor King <wking@drexel.edu> wrote:
The relevant lines from tests/errors/cdef_members_T517.pxd are:
$ grep -n ^ tests/errors/cdef_members_T517.pyx ... 8:ctypedef struct Foo: 9: int i 10: 11:cdef class Bar: 12: cdef Foo foo0 13: cdef readonly Foo foo2 14: cdef public Foo foo1 15: pass ...
...
What's less clear is the behavior of
b = Bar() b.foo1 = Foo(i=1) b.foo1.i = 100 print b.foo1 saved = b.foo1 del b print saved
Is the problem choosing between:
1) Copy struct data into its own PyObject and let Python manage the memory. 2) Pass around a pointer to Cython-managed struct data.
Yes, exactly.
I suppose I don't really know enough about how Cython handles this yet to really see the problem or be able to help with a solution ;).
Cython doesn't handle this yet--that's what we get to decide. Another option would be to use weakrefs to implement copy-on-owner-destruction, but that has even subtler corner semantics. b = Bar() b.foo1 = Foo(i=1) first = b.foo1 second = b.foo1 first.i = 100 print second del b first.i = 200 print second I'm leaning towards (1) for ease and efficiency of implementation and it's easier to explain in all cases. - Robert
participants (2)
-
Robert Bradshaw -
W. Trevor King