[Cython] Expected errors of tests/errors/cdef_members_T517.pxd

[Robert Bradshaw]

On Sat, Feb 26, 2011 at 5:08 AM, W. Trevor King <wking at 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