robertwb / issues-import-test Goto Github PK

Reported by robertwb on 5 May 2008 23:54 UTC
The following produce error messages (regardless of a and n):

a <<= n
a >>= n
a **= n
a //= n

http://docs.python.org/lib/module-operator.html

This is because Pyrex only supported single and two-character operators in its lexicon. (Of course, his should change.)

Migrated-From: http://trac.cython.org/ticket/1

Reported by robertwb on 6 May 2008 00:17 UTC
I create foo.pyx containing either or both of the following statements:

  cdef double INFINITY = float('inf')
  assert True

I build it using Cython 0.9.6.13.1 and gcc 4.1.3. The build succeeds and the code works, but gcc issues the following warning:

  foo.c: In function initfoo:
  foo.c:130: warning: unused variable __pyx_4
  foo.c:129: warning: unused variable __pyx_3

I see no such warnings when building the same code under Cython 0.9.6.12.

Migrated-From: http://trac.cython.org/ticket/6

Reported by rebirth on 18 Jun 2008 20:26 UTC
A common Python programming style is for classes to be configured via initialised class attributes, which allows users to create subclasses with different initial values, for example:

class Foo:
   bar = 5
   baz = "someval"

class MyFoo(Foo):
   bar = 7
   baz = "anotherval"

However, this does not presently work with Cython/Pyrex.

This filing is a request for support of initialised cdef class attributes, eg:

cdef class Foo:
    cdef public int bar = 5
    cdef public object baz = "someval"
...
cdef class MyFoo(Foo):
    cdef public int bar = 7
    cdef public object baz = "anotherval"
...
class AnotherFoo(Foo):
    bar = 8
    baz = "yetanotherval"

In this example, we subclass Foo twice - once with an extension subclass containing initialised cdef class attributes, and the other as a pure-python subclass containing initialised class attributes in pure-python syntax.

Ideally, both idioms would be supported. In the former case, the int value 7 would be written to the attribute 'bar' prior to init, and in the latter case, the int object 8 would be converted to a C integer then written to the attribute bar.

The advantage of supporting these cdef class attribute initialisations is that it would allow users to stick with the python idiom of 'initialised class attributes as configuration option', while allowing the speed advantage of struct-level attribute access (as opposed to the slower getattr at the pure-python level).

Migrated-From: http://trac.cython.org/ticket/18

Reported by dagss on 16 May 2008 16:41 UTC
It should now be possible to do stuff like:

class WithTransform(VisitorTransform):
     # from with transform PEP...
     with_fragment = TreeFragment(u"""
_mgr = (EXPR)
_exit = mgr.__exit__
_value = mgr.__enter__()
_exc = True
try:
     try:
         VAR = _value
         BLOCK
...
<snip>
...
""")

     def process_WithStatementNode(self, node):
         return self.with_fragment.substitute({
             "EXPR" : node.expr,
             "VAR" : node.var,
             "BLOCK" : node.body
         })

:-)

(The above is simplified, there's not always a VAR. Also it needs
another feature before it can be completely streamlined (automatic
"temporaries" that won't clash in the namespace; basically,
"with_fragment.substitute(..., temps=("_mgr", ...)). When that is done,
supporting the with statement is about as much work as extending the
parser, the transform/implementation comes for free.

• I've already discussed the CodeWriter. It only supports a limited
  subset (with some holes, ~30% perhaps) at this time; but it's what I
  need for now (for unit tests). I might work further on that too.
• Some changes to Transform.py which I hope goes through... there's a
  Visitor object there; using the "process_ClassName" pattern (I think
  that was the conclusion for future performance reasons).
• A clone_node method on Node for proper node copying (shallow object
  copy except child node lists, which are also copied).
• Here's the controversial bit:

In order to be able to provide proper error messages for string-based
code snippets like the above (which are passed to Parsing.py...); I've
changed the pointer to the source code (used as the first element in the
position tuples found everywhere...) from being a string filename to
being a SourceDescriptor object.

A SourceDescriptor can currently be a FileSourceDescriptor, in which
case things work like before (it gives the filename on str so much
code needed not change), or a StringSourceDestriptor which I use for my
new code...

I hope you see the advantages to this from the above code. (There are
less intrusive ways to do this, but they would only be hacky and
postpone the problem. Better do it properly...? BTW this pattern is
rather common, consider for instance Source in the XML Transform APIs/TrAX.)

Migrated-From: http://trac.cython.org/ticket/11

Reported by zaphod cython on 2 Jul 2008 00:40 UTC
% echo "from future import division" > foo.pyx
% cython foo.pyx

Error converting Pyrex file to C:

...
from future import division

^

/home/zaphod/shiny/glint/foo.pyx:1:31: future feature division is not defined

Cython 0.9.8 reports the above error. Cython 0.9.6.14 compiles the module successfully.

Migrated-From: http://trac.cython.org/ticket/22

Reported by robertwb on 6 May 2008 00:14 UTC
When subclasses of extension types call the init() method of their supertype, Cython generates code that looks up the "init" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special init() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the init() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.

Migrated-From: http://trac.cython.org/ticket/3

Reported by robertwb on 6 May 2008 00:13 UTC
Currently, Python functions and methods in Cython generated C modules cannot provide their signature to interactive introspection. This is a major problem for the "help()" function in the interpreter (where function signatures look like "parse(...)"), but also to API doc generation tools like epydoc.

epydoc supports a special first line in the docstring here that mimics the look of the signature:

http://epydoc.sourceforge.net/api/epydoc.docstringparser-module.html#parse_function_signature
http://epydoc.sourceforge.net/api/epydoc.docstringparser-pysrc.html#parse_function_signature

Cython could generate such a line based on the original source signature.

Migrated-From: http://trac.cython.org/ticket/2

Reported by robertwb on 6 May 2008 00:19 UTC
Joost Cassee wrote:

Cython (0.9.6.13.1) allow pyx files to be placed in the package directory. When I do so, the accompanying pxd file is not found. An strace of cython shows it uses the package directory twice in building the path:

~/src$ strace cython package/module.pyx
...
stat64("/home/user/src/package/package/module.pxd", 0xbf8b1f48) = -1 ENOENT (No such file or directory)
...

On the other hand, if I name the module as in python I get a cython error:

~/src$ cython package.module.pyx
...
IOError: [2](Errno) No such file or directory: '/home/user/src/package.module.pyx'

On the other hand, an strace shows that the pxd file was found. :-)

Migrated-From: http://trac.cython.org/ticket/7

Reported by robertwb on 6 May 2008 00:15 UTC
Is this form of cimport:

from <package_dir> cimport

officially not supported? It gives "'package.pxd' not found" error.

You can however do

cimport <package_dir>. as

which comes to the same thing...

Migrated-From: http://trac.cython.org/ticket/4

Reported by Dag Sverre Seljebotn on 14 May 2008 19:58 UTC
See the attached test-case -- there was a bug related to raising exceptions from within an iterator.

Migrated-From: http://trac.cython.org/ticket/10

Reported by Dag Sverre Seljebotn on 14 May 2008 19:58 UTC
See the attached test-case -- there was a bug related to raising exceptions from within an iterator.

Migrated-From: http://trac.cython.org/ticket/10

Reported by robertwb on 6 May 2008 00:16 UTC
When defining a class attribute that starts with double underscores, CPython mangles the name from __bla to _classname_bla, but Cython produces classes don't.

Minimal example:

test.pyx and good.py are the same, like so:
class Test(object):
    __bla = 1

alon@alfajor:~/src/bugs/cython/doubleunderscore$ python
Python 2.5.2 (r252:60911, Feb 26 2008, 15:04:22)
[4.2.3 (Ubuntu 4.2.3-2ubuntu1)](GCC) on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> test.Test
<class 'test.Test'>
>>> test.Test.__bla
1
>>>
alon@alfajor:~/src/bugs/cython/doubleunderscore$
alon@alfajor:~/src/bugs/cython/doubleunderscore$ ls
build setup.py test.c test.pyx test.so
alon@alfajor:~/src/bugs/cython/doubleunderscore$ cp test.pyx good.py
alon@alfajor:~/src/bugs/cython/doubleunderscore$ python
Python 2.5.2 (r252:60911, Feb 26 2008, 15:04:22)
[4.2.3 (Ubuntu 4.2.3-2ubuntu1)](GCC) on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import good
>>> good.Test
<class 'good.Test'>
>>> good.Test.__bla
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'Test' has no attribute '__bla'
>>> good.Test._Test__bla
1
>>>

Migrated-From: http://trac.cython.org/ticket/5

Reported by joost on 7 May 2008 19:11 UTC
The fix for bug #220108 introduces a problem when defining a negative
integer:

DEX X = -1

...
File "/usr/lib/python2.5/site-packages/Cython-0.9.6.14-py2.5.egg/
Cython/Compiler/Parsing.py", line 1267, in p_DEF_statement
value = expr.compile_time_value(denv)
File "/usr/lib/python2.5/site-packages/Cython-0.9.6.14-py2.5.egg/
Cython/Compiler/ExprNodes.py", line 674, in compile_time_value
return int(self.value, 0)
TypeError: int() can't convert non-string with explicit base

Cython version 0.9.6.13 worked fine.

Migrated-From: http://trac.cython.org/ticket/8

Reported by JimKleckner on 23 May 2008 21:49 UTC
The attached patch set should be reviewed for inclusion.

Note particularly the change to belchenko1 and comment whether it is appropriate.

Migrated-From: http://trac.cython.org/ticket/13

Reported by JimKleckner on 24 May 2008 01:01 UTC
This is a one-line patch:

Emit code to guard declarations for this module's public functions.

It appears that the machinery is all there to protect the declaration
of inconsistent linkage types (i.e. dllimport vs. dllexport) by using
a guard unique to the pyx file. This patch simply emits that guard
for the current module to prevent the error "inconsistent linkage types"
on a Windows-based system.

Migrated-From: http://trac.cython.org/ticket/14

Reported by robertwb on 6 May 2008 00:15 UTC
Is this form of cimport:

from <package_dir> cimport

officially not supported? It gives "'package.pxd' not found" error.

You can however do

cimport <package_dir>. as

which comes to the same thing...

Migrated-From: http://trac.cython.org/ticket/4

Reported by kirr on 14 May 2008 17:16 UTC
You know, when developing code, it is very tedious to look for meaningful
errors and warnings in presence of tons of noise like

warning: deprecated conversion from string constant to char*

And you know what? It seems in the next version of gcc, this deprecation
warnings will be turned into errors.

Python sources already use 'const' keyword freely, so I think it's time to add
constify bits all over the place.

Migrated-From: http://trac.cython.org/ticket/9

Reported by robertwb on 6 May 2008 00:13 UTC
Currently, Python functions and methods in Cython generated C modules cannot provide their signature to interactive introspection. This is a major problem for the "help()" function in the interpreter (where function signatures look like "parse(...)"), but also to API doc generation tools like epydoc.

epydoc supports a special first line in the docstring here that mimics the look of the signature:

http://epydoc.sourceforge.net/api/epydoc.docstringparser-module.html#parse_function_signature
http://epydoc.sourceforge.net/api/epydoc.docstringparser-pysrc.html#parse_function_signature

Cython could generate such a line based on the original source signature.

Migrated-From: http://trac.cython.org/ticket/2

Reported by Stefan van der Walt stefan on 19 Jun 2008 10:00 UTC
When compiling the following text with '''cython -a''', I get a UnicodeDecodeError:

cdef extern from "Python.h":
    ctypedef int Py_intptr_t

print '  stride %d:' % <Py_intptr_t>3

Traceback (most recent call last):
  File "/Users/stefan/bin/cython", line 8, in <module>
    main(command_line = 1)
  File "/Users/stefan/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 342, in main
    result = context.compile(source, options)
  File "/Users/stefan/lib/python2.5/site-packages/Cython/Compiler/Main.py", line 217, in compile
    tree.process_implementation(scope, options, result)
  File "/Users/stefan/lib/python2.5/site-packages/Cython/Compiler/ModuleNode.py", line 51, in process_implementation
    self.generate_c_code(env, options, result)
  File "/Users/stefan/lib/python2.5/site-packages/Cython/Compiler/ModuleNode.py", line 246, in generate_c_code
    code.save_annotation(result.c_file[+ "pyx") # change?
  File "/Users/stefan/lib/python2.5/site-packages/Cython/Compiler/Annotate.py", line 78, in save_annotation
    lines[line_no](:-1]) = line[+ item + line[col:](:col])
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 0: ordinal not in range(128)

I'm running 726:9527edc22cb6 from Jun 13 20:50:39 2008 +0200.

Migrated-From: http://trac.cython.org/ticket/19

Reported by robertwb on 16 Jul 2008 07:04 UTC

On Jul 7, 2008, at 8:37 PM, Guillaume Chereau wrote:

Hello all,

I am currently using cython for a project related to openmoko cell
phone : http://charlie137-2.blogspot.com/2008/07/introducing-tichy.html

I noticed that the memory is constantly increasing when I use cython. I
tracked down the problem to the case where I create a subclass of a
cython class and then redefine a cpdef method, asking it to call the
parent method, but ONLY if the cpdef method then call an other cpdef
method !

Here is the smallest example I could come with that fails :


== test.pyx ==

cdef class A:
    cpdef func(self):
        return

    cpdef test(self):
         self.func()


== main.py ==

import test
import gc

class B(test.A):
    def test(self):
        test.A.test(self)

b = B()

for i in range(10):
    b.test()
    gc.collect()
    print len(gc.get_objects())


The output will show that some objects are not released.

Is it a known bug ? Is there a way to avoid it ?

Migrated-From: http://trac.cython.org/ticket/24

Reported by robertwb on 6 May 2008 00:14 UTC
When subclasses of extension types call the init() method of their supertype, Cython generates code that looks up the "init" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special init() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the init() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.

Migrated-From: http://trac.cython.org/ticket/3

Reported by robertwb on 5 May 2008 23:54 UTC
The following produce error messages (regardless of a and n):

a <<= n
a >>= n
a **= n
a //= n

http://docs.python.org/lib/module-operator.html

This is because Pyrex only supported single and two-character operators in its lexicon. (Of course, his should change.)

Migrated-From: http://trac.cython.org/ticket/1

Reported by robertwb on 6 May 2008 00:14 UTC
When subclasses of extension types call the init() method of their supertype, Cython generates code that looks up the "init" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special init() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the init() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.

Migrated-From: http://trac.cython.org/ticket/3

Reported by joost on 7 May 2008 19:11 UTC
The fix for bug #220108 introduces a problem when defining a negative
integer:

DEX X = -1

...
File "/usr/lib/python2.5/site-packages/Cython-0.9.6.14-py2.5.egg/
Cython/Compiler/Parsing.py", line 1267, in p_DEF_statement
value = expr.compile_time_value(denv)
File "/usr/lib/python2.5/site-packages/Cython-0.9.6.14-py2.5.egg/
Cython/Compiler/ExprNodes.py", line 674, in compile_time_value
return int(self.value, 0)
TypeError: int() can't convert non-string with explicit base

Cython version 0.9.6.13 worked fine.

Migrated-From: http://trac.cython.org/ticket/8

Reported by kirr on 14 May 2008 17:16 UTC
You know, when developing code, it is very tedious to look for meaningful
errors and warnings in presence of tons of noise like

warning: deprecated conversion from string constant to char*

And you know what? It seems in the next version of gcc, this deprecation
warnings will be turned into errors.

Python sources already use 'const' keyword freely, so I think it's time to add
constify bits all over the place.

Migrated-From: http://trac.cython.org/ticket/9

Reported by robertwb on 6 May 2008 00:13 UTC
Currently, Python functions and methods in Cython generated C modules cannot provide their signature to interactive introspection. This is a major problem for the "help()" function in the interpreter (where function signatures look like "parse(...)"), but also to API doc generation tools like epydoc.

epydoc supports a special first line in the docstring here that mimics the look of the signature:

http://epydoc.sourceforge.net/api/epydoc.docstringparser-module.html#parse_function_signature
http://epydoc.sourceforge.net/api/epydoc.docstringparser-pysrc.html#parse_function_signature

Cython could generate such a line based on the original source signature.

Migrated-From: http://trac.cython.org/ticket/2

Reported by robertwb on 19 Jun 2008 19:01 UTC
For example

__pyx_1 = (__pyx_skip_dispatch = 1, ((struct
__pyx_vtabstruct_4ship_7icewing_7plugins_PluginInstance *)((struct
__pyx_obj_4ship_7icewing_7plugins_PluginInstance
*)__pyx_v_self)->__pyx_vtab)->init(((struct
__pyx_obj_4ship_7icewing_7plugins_PluginInstance *)__pyx_v_self), ((void
*)&((struct
__pyx_opt_args_4ship_7icewing_7plugins_14PluginInstance_init){1,__pyx_v_args}))));

if (unlikely(!__pyx_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 93;
goto __pyx_L1;}

gives

build/temp.linux-x86_64-2.4/pyrex/plugins.c: In function 'PyObject*
__pyx_pf_4ship_7icewing_7plugins_14PluginInstance_init(PyObject*,
PyObject*, PyObject*)':
build/temp.linux-x86_64-2.4/pyrex/plugins.c:1228: error: invalid lvalue
in unary '&'
error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1

Migrated-From: http://trac.cython.org/ticket/21

Reported by robertwb on 6 May 2008 00:13 UTC
Currently, Python functions and methods in Cython generated C modules cannot provide their signature to interactive introspection. This is a major problem for the "help()" function in the interpreter (where function signatures look like "parse(...)"), but also to API doc generation tools like epydoc.

epydoc supports a special first line in the docstring here that mimics the look of the signature:

http://epydoc.sourceforge.net/api/epydoc.docstringparser-module.html#parse_function_signature
http://epydoc.sourceforge.net/api/epydoc.docstringparser-pysrc.html#parse_function_signature

Cython could generate such a line based on the original source signature.

Migrated-From: http://trac.cython.org/ticket/2

Reported by robertwb on 6 May 2008 00:15 UTC
Is this form of cimport:

from <package_dir> cimport

officially not supported? It gives "'package.pxd' not found" error.

You can however do

cimport <package_dir>. as

which comes to the same thing...

Migrated-From: http://trac.cython.org/ticket/4

Reported by robertwb on 7 Jun 2008 06:03 UTC
The following doesn't work:

class Bar(object):
    CONST = 25
    def foo(self, value=CONST):
        pass

Migrated-From: http://trac.cython.org/ticket/17

Reported by robertwb on 6 May 2008 00:13 UTC
Currently, Python functions and methods in Cython generated C modules cannot provide their signature to interactive introspection. This is a major problem for the "help()" function in the interpreter (where function signatures look like "parse(...)"), but also to API doc generation tools like epydoc.

epydoc supports a special first line in the docstring here that mimics the look of the signature:

http://epydoc.sourceforge.net/api/epydoc.docstringparser-module.html#parse_function_signature
http://epydoc.sourceforge.net/api/epydoc.docstringparser-pysrc.html#parse_function_signature

Cython could generate such a line based on the original source signature.

Migrated-From: http://trac.cython.org/ticket/2

Reported by robertwb on 6 May 2008 00:19 UTC
Joost Cassee wrote:

Cython (0.9.6.13.1) allow pyx files to be placed in the package directory. When I do so, the accompanying pxd file is not found. An strace of cython shows it uses the package directory twice in building the path:

~/src$ strace cython package/module.pyx
...
stat64("/home/user/src/package/package/module.pxd", 0xbf8b1f48) = -1 ENOENT (No such file or directory)
...

On the other hand, if I name the module as in python I get a cython error:

~/src$ cython package.module.pyx
...
IOError: [2](Errno) No such file or directory: '/home/user/src/package.module.pyx'

On the other hand, an strace shows that the pxd file was found. :-)

Migrated-From: http://trac.cython.org/ticket/7

Reported by robertwb on 6 May 2008 00:15 UTC
Is this form of cimport:

from <package_dir> cimport

officially not supported? It gives "'package.pxd' not found" error.

You can however do

cimport <package_dir>. as

which comes to the same thing...

Migrated-From: http://trac.cython.org/ticket/4

Reported by robertwb on 6 May 2008 00:16 UTC
When defining a class attribute that starts with double underscores, CPython mangles the name from __bla to _classname_bla, but Cython produces classes don't.

Minimal example:

test.pyx and good.py are the same, like so:
class Test(object):
    __bla = 1

alon@alfajor:~/src/bugs/cython/doubleunderscore$ python
Python 2.5.2 (r252:60911, Feb 26 2008, 15:04:22)
[4.2.3 (Ubuntu 4.2.3-2ubuntu1)](GCC) on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> test.Test
<class 'test.Test'>
>>> test.Test.__bla
1
>>>
alon@alfajor:~/src/bugs/cython/doubleunderscore$
alon@alfajor:~/src/bugs/cython/doubleunderscore$ ls
build setup.py test.c test.pyx test.so
alon@alfajor:~/src/bugs/cython/doubleunderscore$ cp test.pyx good.py
alon@alfajor:~/src/bugs/cython/doubleunderscore$ python
Python 2.5.2 (r252:60911, Feb 26 2008, 15:04:22)
[4.2.3 (Ubuntu 4.2.3-2ubuntu1)](GCC) on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import good
>>> good.Test
<class 'good.Test'>
>>> good.Test.__bla
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'Test' has no attribute '__bla'
>>> good.Test._Test__bla
1
>>>

Migrated-From: http://trac.cython.org/ticket/5

Reported by robertwb on 6 May 2008 00:17 UTC
I create foo.pyx containing either or both of the following statements:

  cdef double INFINITY = float('inf')
  assert True

I build it using Cython 0.9.6.13.1 and gcc 4.1.3. The build succeeds and the code works, but gcc issues the following warning:

  foo.c: In function initfoo:
  foo.c:130: warning: unused variable __pyx_4
  foo.c:129: warning: unused variable __pyx_3

I see no such warnings when building the same code under Cython 0.9.6.12.

Migrated-From: http://trac.cython.org/ticket/6

Reported by robertwb on 5 May 2008 23:54 UTC
The following produce error messages (regardless of a and n):

a <<= n
a >>= n
a **= n
a //= n

http://docs.python.org/lib/module-operator.html

This is because Pyrex only supported single and two-character operators in its lexicon. (Of course, his should change.)

Migrated-From: http://trac.cython.org/ticket/1

Reported by robertwb on 6 May 2008 00:19 UTC
Joost Cassee wrote:

Cython (0.9.6.13.1) allow pyx files to be placed in the package directory. When I do so, the accompanying pxd file is not found. An strace of cython shows it uses the package directory twice in building the path:

~/src$ strace cython package/module.pyx
...
stat64("/home/user/src/package/package/module.pxd", 0xbf8b1f48) = -1 ENOENT (No such file or directory)
...

On the other hand, if I name the module as in python I get a cython error:

~/src$ cython package.module.pyx
...
IOError: [2](Errno) No such file or directory: '/home/user/src/package.module.pyx'

On the other hand, an strace shows that the pxd file was found. :-)

Migrated-From: http://trac.cython.org/ticket/7

Reported by robertwb on 6 May 2008 00:17 UTC
I create foo.pyx containing either or both of the following statements:

  cdef double INFINITY = float('inf')
  assert True

I build it using Cython 0.9.6.13.1 and gcc 4.1.3. The build succeeds and the code works, but gcc issues the following warning:

  foo.c: In function initfoo:
  foo.c:130: warning: unused variable __pyx_4
  foo.c:129: warning: unused variable __pyx_3

I see no such warnings when building the same code under Cython 0.9.6.12.

Migrated-From: http://trac.cython.org/ticket/6

Reported by dan on 19 Jun 2008 14:53 UTC
It seems if you have a method in a class with an argument typed to be
an "ndarray":

cdef class base:
    cdef void func(self, ndarray arr): pass

and you then try to override the method in a derived class, you get
errors. Things work fine if the type of the argument is an "int", or
if both base and derived class are in the same file.

I think this happens because "ndarray" is not a cdef class kind of a
type, but comes in from an outside library -- numpy -- as a:

ctypedef extern class numpy.ndarray [PyArrayObject](object):

Here is what happens when you run:

• python cython.py base.pyx
• gcc -c -fPIC -O6 -fno-strict-aliasing -I/usr/include/python2.3 base.c
• gcc -shared -lm base.o -o base.so
• python cython.py main.pyx

Error converting Pyrex file to C:
------------------------------------------------------------
...

cdef class item(base.base):

    #cdef void method(me, int arr): pass

    cdef void method(me, ndarray arr): pass     ^
------------------------------------------------------------

/home/dg/w/pex/Tickets/01_ndarray_as_overridden_arg/main.pyx:8:6: Signature not compatible with previous declaration

Error converting Pyrex file to C:
------------------------------------------------------------
...
include "numpy.pxi"

cdef class base:

    #cdef void method(me, int arr)
    cdef void method(me, ndarray arr)                ^
------------------------------------------------------------

/home/dg/w/pex/Tickets/01_ndarray_as_overridden_arg/base.pxd:7:17: Previous declaration is here

Migrated-From: http://trac.cython.org/ticket/20

Reported by robertwb on 5 May 2008 23:54 UTC
The following produce error messages (regardless of a and n):

a <<= n
a >>= n
a **= n
a //= n

http://docs.python.org/lib/module-operator.html

This is because Pyrex only supported single and two-character operators in its lexicon. (Of course, his should change.)

Migrated-From: http://trac.cython.org/ticket/1

Reported by robertwb on 16 Jul 2008 06:51 UTC

On Jul 11, 2008, at 11:50 PM, Joshua Kantor wrote:

cdef readonly actually works with the numpy arrays,
cdef public does not however. In principle it should be possible to assign a to it, but you of course could only assign a numpy array.

There is code to do c-type conversion on assignment, it shouldn't be hard to do type checking too

Migrated-From: http://trac.cython.org/ticket/23

Reported by robertwb on 5 May 2008 23:54 UTC
The following produce error messages (regardless of a and n):

a <<= n
a >>= n
a **= n
a //= n

http://docs.python.org/lib/module-operator.html

This is because Pyrex only supported single and two-character operators in its lexicon. (Of course, his should change.)

Migrated-From: http://trac.cython.org/ticket/1

Reported by robertwb on 6 May 2008 00:16 UTC
When defining a class attribute that starts with double underscores, CPython mangles the name from __bla to _classname_bla, but Cython produces classes don't.

Minimal example:

test.pyx and good.py are the same, like so:
class Test(object):
    __bla = 1

alon@alfajor:~/src/bugs/cython/doubleunderscore$ python
Python 2.5.2 (r252:60911, Feb 26 2008, 15:04:22)
[4.2.3 (Ubuntu 4.2.3-2ubuntu1)](GCC) on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
>>> test.Test
<class 'test.Test'>
>>> test.Test.__bla
1
>>>
alon@alfajor:~/src/bugs/cython/doubleunderscore$
alon@alfajor:~/src/bugs/cython/doubleunderscore$ ls
build setup.py test.c test.pyx test.so
alon@alfajor:~/src/bugs/cython/doubleunderscore$ cp test.pyx good.py
alon@alfajor:~/src/bugs/cython/doubleunderscore$ python
Python 2.5.2 (r252:60911, Feb 26 2008, 15:04:22)
[4.2.3 (Ubuntu 4.2.3-2ubuntu1)](GCC) on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import good
>>> good.Test
<class 'good.Test'>
>>> good.Test.__bla
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'Test' has no attribute '__bla'
>>> good.Test._Test__bla
1
>>>

Migrated-From: http://trac.cython.org/ticket/5

Reported by jmickelin on 5 Jun 2008 08:23 UTC
Normally, IF only works in the global scope.
Defining conditional members of a struct necessitates redefining the whole structure:

IF UNAME_SYSNAME == "Windows":
      ctypedef struct ohmygod:
            int common
            int greece
ELSE:
      ctypedef struct ohmygod:
            int common
            float pelvis

This would be more convenient, especially for big structures:

ctypedef struct ohmygod:
     int common
     IF UNAME_SYSNAME == "Windows":
                 int greece
     ELSE:
                 float pelvis

Migrated-From: http://trac.cython.org/ticket/16

Reported by robertwb on 6 May 2008 00:14 UTC
When subclasses of extension types call the init() method of their supertype, Cython generates code that looks up the "init" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special init() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the init() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.

Migrated-From: http://trac.cython.org/ticket/3

Reported by kirr on 14 May 2008 17:16 UTC
You know, when developing code, it is very tedious to look for meaningful
errors and warnings in presence of tons of noise like

warning: deprecated conversion from string constant to char*

And you know what? It seems in the next version of gcc, this deprecation
warnings will be turned into errors.

Python sources already use 'const' keyword freely, so I think it's time to add
constify bits all over the place.

Migrated-From: http://trac.cython.org/ticket/9

Reported by robertwb on 28 May 2008 06:34 UTC
Pyrex implemented this here

http://hg.cython.org/pyrex/rev/9a5d15e9acd3

Unfortunately the attached patch (modified a bit for Cython) doesn't apply cleanly.

Migrated-From: http://trac.cython.org/ticket/15

Reported by joost on 7 May 2008 19:11 UTC
The fix for bug #220108 introduces a problem when defining a negative
integer:

DEX X = -1

...
File "/usr/lib/python2.5/site-packages/Cython-0.9.6.14-py2.5.egg/
Cython/Compiler/Parsing.py", line 1267, in p_DEF_statement
value = expr.compile_time_value(denv)
File "/usr/lib/python2.5/site-packages/Cython-0.9.6.14-py2.5.egg/
Cython/Compiler/ExprNodes.py", line 674, in compile_time_value
return int(self.value, 0)
TypeError: int() can't convert non-string with explicit base

Cython version 0.9.6.13 worked fine.

Migrated-From: http://trac.cython.org/ticket/8

Reported by robertwb on 5 May 2008 23:54 UTC
The following produce error messages (regardless of a and n):

a <<= n
a >>= n
a **= n
a //= n

http://docs.python.org/lib/module-operator.html

This is because Pyrex only supported single and two-character operators in its lexicon. (Of course, his should change.)

Migrated-From: http://trac.cython.org/ticket/1

Reported by JimKleckner on 23 May 2008 00:41 UTC
The previous patch that fixed the redefinition of !__stdcall on Cygwin caused
the Windows platform to fail to recognize the calling convention.

The attached patch adds a check for MS_WINDOWS as well before !__stdcall is turned off.

Migrated-From: http://trac.cython.org/ticket/12