2

So, I guess this is a bug in one of the involved packets and I want to report it, but I don't really understand where exactly the error is so I'm trying to define it and describe the solution.

I recently upgraded to Ubuntu 14.4 and was very happy to be able to use it in my own language, when I ran into an error, which is due to the language changes:

When trying to compile cython .pyx files using distutils, the compilation aborts with a unicode error, if the files are in a path, which includes non-ascii symbols. In my case the desktop path has been renamed to the german version "Arbeitsfläche", where there seem to be problems when compiling.

Can anybody tell me if this is a bug or a feature (and if the former, where to submit)?

Stack trace for completeness:

Compiler crash traceback from this point on:
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Nodes.py", line 6785, in analyse_declarations
    module_scope = env.find_module(self.module_name, self.pos)
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Symtab.py", line 1089, in find_module
    module_name, relative_to = self.parent_module, pos = pos)
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line 132, in find_module
    pxd_pathname = self.find_pxd_file(qualified_name, pos)
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line 184, in find_pxd_file
    pxd = self.search_include_directories(qualified_name, ".pxd", pos, sys_path=True)
  File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line 225, in search_include_directories
    tuple(self.include_directories), qualified_name, suffix, pos, include, sys_path)
  File "/usr/lib/python2.7/dist-packages/Cython/Utils.py", line 16, in wrapper
    res = cache[args] = f(*args)
  File "/usr/lib/python2.7/dist-packages/Cython/Utils.py", line 101, in search_include_directories
    path = os.path.join(dir, dotted_filename)
  File "/usr/lib/python2.7/posixpath.py", line 80, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 23: ordinal not in range(128)

Edit 18.8.2014

A minimal example can be found here. It seems, that the import cython statement triggers the behaviour.

Dschoni
  • 3,714
  • 6
  • 45
  • 80
  • Non-ASCII file names are a common problem in Python 2.x. It often helps to explicitly use the `u` prefix to mark string literals as unicode, i.e. to write `u"Arbeitsfläche"`. If you haven't hardcoded the name into your program, please amend your post with a short example. I haven't been able to reproduce your error with a simple distutils-compiled cython module here. – Phillip Aug 18 '14 at 12:00
  • @Phillip: As mentioned already in my question, the error only appears when I try to compile a pyx file in a place which has unicode symbols in its name. To reproduce, simply create a folder with some non-ASCII name and try to compile inside that folder. It seems to be an error from the compiler rather than from my programming. – Dschoni Aug 18 '14 at 12:17
  • I tried that, with Python 2.7.5 and Cython 0.20.2. [Here's my test code](https://gist.github.com/phillipberndt/207d109cd345c054ef57), which I could compile in a folder named "ÄÖÜß" without any errors/warnings. – Phillip Aug 18 '14 at 12:58
  • Thanks a lot, this helps me searching for the reason in the correct direction. It seems to have to do with the cython importing in one of my modules. I forked your code, to represent a minimal example, which shows the behaviour at [this location](https://gist.github.com/Dschoni/4bebd2e6f283adf2563e). As soon as the import cython line is omitted everything works. – Dschoni Aug 18 '14 at 17:26

1 Answers1

1

I've managed to compile your example after I replaced the arguments to setup

ext_modules=linext,
cmdclass = {'build_ext': build_ext}

with the version that is encouraged in the current cython documentation:

ext_modules=cythonize(linext)

Depending on where you've found your version, there either really is a bug in Cython, or you simply tried something which does not work.

Phillip
  • 13,448
  • 29
  • 41
  • I guess this is leading in the correct direction. Nevertheless for my (more complicated) setup file, this produces the same error. I'm trying to work bottom up to see, where the error is introduced. – Dschoni Aug 20 '14 at 12:46