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

W. Trevor King wking at drexel.edu
Sat Feb 26 14:08:41 CET 2011


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110226/ac4d793b/attachment.pgp>


More information about the cython-devel mailing list