[Cython] Bug: bad C code generated for (some) "... and ... or ..." expressions
"cython 0.13" generates bad C code for the attached "pyx" file.
"cython" itself recognizes that it did something wrong and emits ";"
to the generated file:
...
static __pyx_t_12cybug_and_or_pointer __pyx_f_12cybug_and_or_bug(PyObject
*__pyx_v_o) {
__pyx_t_12cybug_and_or_pointer __pyx_r;
int __pyx_t_1;
__pyx_t_12cybug_and_or_pointer __pyx_t_2;
;
;
...
ctypedef void * pointer
cdef extern from "nonexistant.h":
cdef pointer to_pointer(object)
cdef pointer bug(o):
return o is not None and to_pointer(o) or NULL
The error probably happens because it is difficult for "cython" to
determine the type for "and" and "or" expressions (if the operand types
differ). In an "cond and t or f" expression, however, the result type
is "type(t)" if "type(t) == type(f)", independent of "type(cond)".
It might not be worse to special case this type of expressions.
It would however be more friendly to output an instructive
error message instead of generating bad C code.
--
Dieter
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Why does "__cinit__" insists on converting its arguments to Python objects?
The following cython source leads to a "Cannot convert 'pointer' to Python object". ctypedef void * pointer cdef extern from "nonexistant.h": cdef pointer to_pointer(object) cdef class C: cdef pointer p def __cinit__(self, pointer p): self.p = p c = C(to_pointer(None)) Why does the constructor call tries an implicit conversion to a Python object even though it gets precisely the type indicated by its signature? I am working on a binding for "libxmlsec". The behaviour above leads to an unnatural mapping. Two examples: 1. "libxmlsec" has the concept of a key (used for digital signatures or encryption), naturally mapped onto a "cdef class Key" encapsulating the xmlsec key pointer. "libxmlsec" provides many functions to create keys - naturally mapped onto class methods used as alternative constructors. Would "Cython" allow C level parameters for "__cinit__", they could look like: cdef xmlSecKeyPtr xkey = ... some "libxmlsec" key generating function ... return Key(xkey) With the restriction, this must look like: cdef Key key key.xkey = ... some "libxmlsec" key generating function ... return key Not yet too bad, unless the constructor requires C level arguments. 2. "libxmlsec" provides a whole bunch of transforms, handled in C code via a set of so called "TransformId"s. Each "TransformId" is generated by a function. The natural way would like: cdef class TransformId: cdef xmlSecTransformId tid def __cinit__(self, xmlSecTransformId tid): self.tid = tid TransformInclC14N = TransformId(xmlSecTransformInclC14NGetKlass()) ... for all standard transforms ... The restriction forces the introduction of a helper function: cdef class TransformId: cdef xmlSecTransformId tid cdef _mkti(xmlSecTransformId tid): cdef TransformId t = TransformId() t.tid = tid return t TransformInclC14N = _mkti(xmlSecTransformInclC14NGetKlass()) ... for all standard transforms ... -- Dieter ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Bug: bad C code generated for (some) "... and ... or ..." expressions
Stefan Behnel wrote at 2012-6-8 08:50 +0200: >thanks for the report. > >Dieter Maurer, 07.06.2012 10:44: >> "cython 0.13" generates bad C code for the attached "pyx" file. > >Could you try the latest release? I would at least expect an error instead >of actually generating code. The latest release on PyPI is "0.16". It behaves identical to version "0.13": no error message; just wrongly generated C code (C code containing ";" "statements". -- Dieter ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Feature request: generate signature information for use by "inspect"
Python's "inspect" module is a great help to get valuable information about a package. Many higher level tools (e.g. the "help" builtin and "pydoc") are based on it. I have just recognized a deficiency of "cython" generated modules with respect to "inspect" support: "inspect" cannot determine the signatures for Python functions defined in "Cython" source. I understand that this might be a limitation of Python's "C" interface. In this case, I suggest to enhance the function's docstring by signature information. I now transform manually my docstrings def (): """ """ into: def (): """() -> : """ and would be happy to get something similar automatically. -- Dieter ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Feature request: generate signature information for use by "inspect"
Stefan Behnel wrote at 2012-6-28 09:25 +0200: >Dieter Maurer, 28.06.2012 09:04: >> ... >> In this case, I suggest to enhance the >> function's docstring by signature information. >> >> I now transform manually my docstrings >> >> def (): >>""" >> >> >>""" >> >> into: >> >> def (): >>"""() -> : >> >> >>""" >> >> and would be happy to get something similar automatically. > >And the time machine strikes again. You can use the "embedsignature" >compiler option for that. > >http://docs.cython.org/src/reference/compilation.html?highlight=embedsignature#compiler-directives Thank you! I missed this part of the documentation. -- Dieter ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Potential bug: hole in "C <-> Python" conversion
I have cdef extern from *: ctypedef char const_unsigned_char "const unsigned char" cdef const_unsigned_char *c_data = data leads to "Cannot convert Python object to 'const_unsigned_char *'" while "cdef char *c_data = data" works. Should the "ctypedef char const_unsigned_char" not ensure that "char" and "const_unsigned_char" are used as synonyms? -- Dieter ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Potential bug: hole in "C <-> Python" conversion
Stefan Behnel wrote at 2012-6-29 11:42 +0200:
>Dieter Maurer, 29.06.2012 11:25:
>> I have
>>
>> cdef extern from *:
>> ctypedef char const_unsigned_char "const unsigned char"
>
>This is an incorrect declaration. "char" != "unsigned char".
You are right. I cheat to get "Cython" convert between "unsigned char*"
and "bytes" in the same way as it does for "char *".
For this conversion, there is no real difference between
"char *" and "unsigned char *" (apart from a C level warning
about a pointer of a bad type passed to "PyString_FromStringAndSize").
>> cdef const_unsigned_char *c_data = data
>>
>> leads to "Cannot convert Python object to 'const_unsigned_char *'"
>> while "cdef char *c_data = data" works.
>>
>> Should the "ctypedef char const_unsigned_char" not ensure
>> that "char" and "const_unsigned_char" are used as synonyms?
>
>I assume you are not using the latest Cython (0.17pre) from github, are
>you? It should have a fix for this.
You are right.
I am using the "cython" version which comes with my operating
system ("cython 0.13").
Very good, if the latest "Cython" behaves better :-)
>Also note that libc.string contains declarations for "const char*" and friends.
Unformatunately, I need "const unsigned char*" and "const xmlChar *"
(where "xmlChar" is defined as "unsigned char").
I used the "libc.string" definitions as a blueprint for mine.
--
Dieter
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
