I'm starting to play with the library pybind11. It's really good library, well documented and it works for me but only with Python 2.7. I'm not able to get it working for Python 3.5 and I don't know what I'm doing wrong.
This is my "hello world" program:
#include <pybind11/pybind11.h>
namespace py = pybind11;
const char * world() { return "Hello world!"; }
int main(int argc, char ** argv) {
Py_Initialize();
py::module m("hello", "my hello world Python module with pybind11");
m.def("world", &world);
PyRun_SimpleString("import hello\nprint( hello.world() )");
Py_Finalize();
return 0;
}
If I compile and link against 2.7, I get the expected result:
Hello world!
But if I link exactly the same code with Python 3.5, I get an error loading the module.
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named 'hello'
Any ideas?
How did you compile the library and what system are you on? If you used python-config as suggested in the basic example in their documentation (the command below), you'll compile against the development version on your machine.
c++ -O3 -shared -std=c++11 -I <path-to-pybind11>/include `python-config --cflags --ldflags` example.cpp -o example.so
This is likely Python 2.7 even if you use Python 3.5. In my case, I used Anaconda to install python, and that gave me Python 3.5, but the system Python is still 2.7.
What does python-config give you? Is the version listed Python 3.5? If it is not you cannot use this command at least without modifications. What you can do is cmake build system as described in their documentation. That fixed it for me. Using their setuptools system, would probably also work. Basically, they figure out what you used to compile their library and use those flags. This does mean, that you have to make sure that you are linking against Python 3.5 when building the library itself.
Related
I have referred some websites to build pyx to pyd in Windows 8.1.I 'm using Anaconda Distribution with Spyder IDE, I have developed pyx file and unable to build in "Anaconda Command Prompt"
Anaconda>
python setup.py build --inplace --compiler=mingw32
and tried
python setup.py build_ext --inplace --compiler=mingw32
getting following error:
File "C:\ProgramData\Anaconda3\lib\distutils\cygwinccompiler.py", line 129 in __init__
if self.ld_version >= "2.10.90":
TypeError: '>=' not supported between instances of 'NoneType' and 'str'
my simple pyx code is
cdef int fib(int n):
cdef int a, b, i
a, b = 1, 1
for i in range(n):
a, b = a+b, a
return a
and my setup.py file as below..
from distutils.core import setup
from Cython.Build import cythonize
setup(ext_modules = cythonize('fb.pyx'))
Howto get rid of this in windows 8.1? I would like use Struct and Socket libraries for my socket programming.
There's nothing wrong with your .pyx or setup.py code AFAICT.
I am using Anaconda3 on windows 10 and it works.
The issue is with the compiler. Did you install mingw32 yourself?
It looks like whichever version you have cannot compile the code.
I got the same error for cygwin
But, the code compiled fine for me using the compiler included in Visual Studio 14 and the borlands compiler.
Try --compiler=bcpp (hopefully already be on your system)
or
Try installing: http://landinghub.visualstudio.com/visual-cpp-build-tools
and run your compile command with --compiler=msvc (or just without specifying the compiler.)
I'm making a program using Python2.7 and Kivy1.9.2-dev, and trying to package it with PyInstaller-3.0 for different systems as a single executable.
The systems I'm trying to package it for are these:
64-bit Linux Mint 17.3
32-bit Linux Mint 17 (also tried while upgrading to 17.1 and 17.3)
32-bit Windows XP SP3
Raspbian (Raspberry Pi)
On all these systems the program is working well when just run with Python, uncompiled. (so, all Kivy dependencies are fine, too).
However, out of the executables made with PyInstaller, only the one made on 64-bit Linux works as one file. The Windows and Raspbian executables mostly work (I'll write about it later), but the one made on 32-bit Linux still doesn't run. It gives the following error when run (I tried running it on both 32 and 64-bit Linux):
Traceback (most recent call last):
File "<string>", line 11, in <module>
File "/media/Data/Programming/Python/installers/PyInstaller-3.0/PyInstaller/loader/pyimod03_importers.py", line 363, in load_module
exec(bytecode, module.__dict__)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 48, in <module>
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/extern/__init__.py", line 60, in load_module
ImportError: The 'six' package is required; normally this is bundled with this package so if you get this warning, consult the packager of your distribution.
pyi_rth_pkgres returned -1
Here's what I'm confused about:
Inside my "/usr/local/lib/python2.7/dist-packages/" there is no "pkg_resources" folder, but the above indicates that it, apparently, is there... It even reads the files there successfully. Is it something that gets created just when the executable starts?
I don't specifically use "six" for anything, before this error I didn't even know it existed.
"Six" IS installed on my system, as confirmed by the Package Manager and by Pip. It's located in "/usr/local/lib/python2.7/dist-packages/". I guess PyInstaller can't find it for some reason (as, I believe, if everything is packaged correctly it doesn't have to be there on the system where the executable is run.)
So, my question is pretty typical, what may cause this problem for PyInstaller (just in case, I DID run the "setup.py install" for it), and how to get around/fix it?
Thanks!
PS: On a side note, I mentioned the problems with Windows and Raspbian executables. On Windows, the exe only runs when there is "zlib1.dll" present in the same folder (even if specifically packaged into the exe with PyInstaller, it doesn't work), and on Raspbian I only got the program working without using "--onefile" (with "--onefile", it seems PyInstaller doesn't package any Python binaries into the executable, like libpython.2.7.so, and maybe others too)
Well, adding 'six' into hidden packages, as Clement suggested, didn't work, but started a sequence of trial-and-error that finally led to a solution.
After the test with "hiddenimports" didn't work I tried just importing 'six' into my Python code. And the compiled executable no longer showed this error! However, it now said that the package named 'packaging' is required... Which I didn't have installed.
To put it short, starting from the initial problem, I did this:
Installed 'packaging' using 'pip':
sudo pip install packaging
Added these imports into my main Python code:
import six
import packaging
import packaging.version
import packaging.specifiers
(all the imports added were trial-and-error, done until the PyInstaller-made executable finally worked).
Seems a bit hack-y, as making the executable for a 64-bit Linux didn't require any of these imports, but at least it now works, and the executable size is basically unaffected.
For the following setup (anaconda):
PyInstaller: 3.2
Python: 3.5.2
Platform: Windows-10-10.0.10240-SP0
Numpy: 1.11.1
And the following mwe.py:
import numpy
print ("hello world")
I had to do the following to fix:
pip install packaging
Build with the following bat file (^ is the BAT line continuation):
pyinstaller --noconfirm ^
--hidden-import six ^
--hidden-import packaging ^
--hidden-import packaging.version ^
--hidden-import packaging.specifiers ^
--hidden-import packaging.requirements ^
mwe.py
I had a similar problem. Try to add "six" as well as "kivy" to the hidden_packages in your spec file. If it doesn't work, make sure that setuptools is installed in its 19.2 version. It seemed to be the problem for me on Windows. Hope it helps.
I need to call C libraries with python, and after some consideration it seemed CFFI would be most adequate for the kind of job. By now, however, I am thouroughly confused if I'm using it right, because some things seem to work as intended only on PyPy, while others seem to work only on Python3 (which PyPy doesn't support, as far as I know).
Here's the most basic code sample from the CFFI documentation:
>>> from cffi import FFI
>>> ffi = FFI()
>>> ffi.cdef("""
... int printf(const char *format, ...); // copy-pasted from the man page
... """)
>>> C = ffi.dlopen(None) # loads the entire C namespace
>>> arg = ffi.new("char[]", "world") # equivalent to C code: char arg[] = "world";
>>> C.printf("hi there, %s.\n", arg) # call printf
hi there, world.
17 # this is the return value
>>>
When running this code with Python3, I get the following error:
TypeError: initializer for ctype 'char[]' must be a bytes or list or tuple, not str
Looking for the error, I found it as an issue that was fixed in January last year in PyPy. So I see if the thing runs with PyPy, and it does. Hooray!
However, already in the second example, I'm getting the problem in reverse:
# file "simple_example_build.py"
# Note: this particular example fails before version 1.0.2
# because it combines variadic function and ABI level.
from cffi import FFI
ffi = FFI()
ffi.set_source("_simple_example", None)
ffi.cdef("""
int printf(const char *format, ...);
""")
if __name__ == "__main__":
ffi.compile()
Running this in PyPy throws another error at me:
AttributeError: 'FFI' object has no attribute 'set_source'
Since the example states helpfully that it won't work on older versions, I checked my CFFI version: 1.2.1, everything's alright.
Finally I run the second example with Python3 instead of PyPy, and who would have thought, it does exactly what it's supposed to do.
Being new to Python, by now I don't really have a clue anymore what I am supposed to use, and why the examples from the same documentation only run on different versions of the language. And there's of course still the problem that I might just have configured something wrong (what with being new to Linux too), or that I should use another python version altogether. Could somebody shed some light on this?
When running this code with Python3, I get the following error: TypeError: initializer for ctype 'char[]' must be a bytes or list or tuple, not str
Yes, because for Python 3 you need to use the 'b' prefix to make sure you are handling bytes. The example in the docs states this clearly just below.
AttributeError: 'FFI' object has no attribute 'set_source'
This means that you have an old version of PyPy. The version of CFFI cannot be upgraded in a given version of PyPy; you need to upgrade PyPy itself. Check which CFFI version your particular PyPy comes with like this:
$ pypy
Python 2.7.9 (295ee98b6928, May 31 2015, 07:29:04)
[PyPy 2.6.0 with GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> import cffi
>>>> cffi.__version__
'1.1.0'
I'm pretty sure you're using an older version of PyPy that comes with an older version of CFFI, not 1.2.1.
you can modify it as below:
from cffi import FFI
ffi = FFI()
ffi.cdef("""int printf(const char *format, ...);""")
C = ffi.dlopen(None) # loads the entire C namespace
arg = ffi.new("char[]", b"world") # equivalent to C code: char arg[] = "world";
C.printf(b"hi there, %s.\n", arg) # call printf
I am using Anacondas on a 64-bit Windows machine.
I have compiled a hello world Cython example. It is in file hello.pyx, and contains:
def say_hello_to(name):
print("Hello %s!" % name)
I am running it using run_hello.py
import pyximport; pyximport.install()
import hello as hello
hello.say_hello_to('jon')
The setup file is setup.py:
from distutils.core import setup
from Cython.Build import cythonize
setup(
name = 'Hello world app',
ext_modules = cythonize("hello.pyx"),
)
I am then compiling the code in Python 3.3 on Anacondas, using this code:
> activate py33
> python setup.py build_ext --inplace
( please note that py33 is my Python 3.3 environment )
I can then run the example:
python run_hello.py
which prints out "Hello jon!" as expected.
Now if I change my environment to Python 3.4 and compile:
> activate py34
> python setup.py build_ext --inplace
I get no error, and the shell displays
running build_ext
However, if I try to run run_hello.py from the py34 environment with:
python run_hello.py
I get:
Traceback (most recent call last):
File "run_hello.py", line 2, in <module>
import hello as hello
ImportError: DLL load failed: The specified module could not be found.
The error is not very descriptive. What could I do to help me make this work on Python 3.4?
If I delete hello.c and the /build folder from my hard drive, trying to compile from Python 3.4 returns:
Compiling hello.pyx because it changed.
Cythonizing hello.pyx
running build_ext
building 'hello' extension
creating build
creating build\temp.win-amd64-3.4
creating build\temp.win-amd64-3.4\Release
C:\Anaconda\envs\py34\Scripts\gcc.bat -mdll -O -Wall -IC:\Anaconda\envs\py34\include -IC:\Anaconda\envs\py34\include -c hello.c -o build\temp.win-amd64-3.4\Release\hello.o
writing build\temp.win-amd64-3.4\Release\hello.def
C:\Anaconda\envs\py34\Scripts\gcc.bat -shared -s build\temp.win-amd64-3.4\Release\hello.o build\temp.win-amd64-3.4\Release\hello.def -LC:\Anaconda\envs\py34\libs -LC:\Anaconda\envs\py34\PCbuild\amd64
-lpython34 -lmsvcr100 -o c:\Users\Jon\Documents\GitHub\CythonFunctions\example1\hello.pyd
build\temp.win-amd64-3.4\Release\hello.o:hello.c:(.text+0x314): undefined reference to `__imp__PyThreadState_Current'
build\temp.win-amd64-3.4\Release\hello.o:hello.c:(.text+0x493): undefined reference to `__imp__Py_NoneStruct'
build\temp.win-amd64-3.4\Release\hello.o:hello.c:(.text+0x97b): undefined reference to `__imp_PyExc_ImportError'
collect2.exe: error: ld returned 1 exit status
error: command 'C:\\Anaconda\\envs\\py34\\Scripts\\gcc.bat' failed with exit status 1
If I do the same with Python 3.3, I get:
Compiling hello.pyx because it changed.
Cythonizing hello.pyx
running build_ext
building 'hello' extension
creating build
creating build\temp.win-amd64-3.3
creating build\temp.win-amd64-3.3\Release
C:\Anaconda\envs\py33\Scripts\gcc.bat -DMS_WIN64 -mdll -O -Wall -IC:\Anaconda\envs\py33\include -IC:\Anaconda\envs\py33\include -c hello.c -o build\temp.win-amd64-3.3\Release\hello.o
writing build\temp.win-amd64-3.3\Release\hello.def
C:\Anaconda\envs\py33\Scripts\gcc.bat -DMS_WIN64 -shared -s build\temp.win-amd64-3.3\Release\hello.o build\temp.win-amd64-3.3\Release\hello.def -LC:\Anaconda\envs\py33\libs -LC:\Anaconda\envs\py33\PCb
uild\amd64 -lpython33 -lmsvcr100 -o c:\Users\Jon\Documents\GitHub\CythonFunctions\example1\hello.pyd
Some other users who experience the "gcc.bat failed with exit status 1" have found that the problem is due to 32/64 bit conflicts.
In the py33 version of the compilation data, there is -DMS_WIN64 in the gcc.bat parameters, but it is not in the py34 parameters. Could that be what is causing my issue? If so, how do I get py34 to add it?
I had been using TDM-GCC as the 64-bit compiler with Python 2.7 64-bit for several years without any problems, but after installing Python 3.4 64-bit, I did have problems compiling a Cython module.
I believe I fixed this issue with mingw-w64-for-python. (Also take a look at this github issue).
There is a readme (currently mingwpy-2015-04-readme.pdf), so it is straightforward. But briefly you need to do:
Download mingwpy x86-64 toolchain (64 bit) (currently mingw64static-2014-11.tar.xz)
Unpack the file into a directory (e.g., C:\mingw64static)
Add C:\mingw64static\bin in front of C:\Anaconda3\Scripts in your Path
environmental variable.
Follow the instructions in the readme file to download libpython. (I used
libpython-cp34-none-win_amd64.7z for Python 3.4 64 bit)
Unpack, and copy files (libmsvcr100.a, libpython34.dll.a) in the archive into C:\Python\libs\ directory (for Anaconda, it is C:\Anaconda3\libs)
Create a file called distutils.cfg in your C:\Python\Lib\distutils
directory (for Anaconda, it is C:\Anaconda3\Lib\distutils) with the
following contents:
[build]
compiler=mingw32
Now python will correctly use mingw-w64 when you compile your cython module.
It looks like the py33 environment is compiling using Visual Studio (-lmsvcr100). This is probably because it doesn't have the libpython conda package installed in it, which causes distutils to use mingw (gcc) to compile instead of Visual Studio. conda remove libpython will likely solve the issue for your Python 3.4 environment.
I want to try Mako with Django instead of Django's default template language. But I'm having a problem when I try to import Mako's Template class as written in the manual:
from mako.template import Template
mytemplate = Template("hello world!")
print mytemplate.render()
I do this in Windows cmd and receive such an error:
C:\Documents and Settings\User>cd C:\py\project\vendor\template\Mako_73 // cd to where I unpacked Mako
C:\py\project\vendor\template\Mako_73>python // run Python interpreter
>>> from mako.template import Template // trying to import and getting an error
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File ".\mako\template.py", line 622
exec code in module.__dict__, module.__dict__
^
SyntaxError: invalid syntax
The code from that part:
def _compile_text(template, text, filename):
identifier = template.module_id
source, lexer = _compile(template, text, filename,
generate_magic_comment=template.disable_unicode)
cid = identifier
if not util.py3k and isinstance(cid, unicode):
cid = cid.encode()
module = types.ModuleType(cid)
code = compile(source, cid, 'exec')
exec code in module.__dict__, module.__dict__
return (source, module)
What can it be? I couldn't find anything in Google about this error.
I'm using Python 3.3.
I've downloaded Mako-0.7.3 as tar.gz file and just unzipped it in
C:\py\poject\vendor\template\Mako_73. I do not have this directory in the PYTHONPATH or paths.pth. C:\py\poject is a directory where my Django project lives and in \vendor\template I've decided to put Mako and import it from there.
UPD
I found the solution. I've installed the Pyramid Framework and have taken the Mako from there as the Mako is a default template system in it. And Pyramid's version works fine.
Your basic problem is that you are using Python 3, which is relatively new for large projects like Django.
Secondly, you need to find out how to install packages correctly. I don't know where you got Mako from, but you won't find anywhere that says "just unpack the tarball" - perhaps you are assuming that from your knowledge of PHP, but it's not correct.
On the Mako site, the suggested method of installation is pip.
If you go for downloading manually, you need to read instructions about installing Python packages, for example here: http://wiki.python.org/moin/CheeseShopTutorial
The reason Mako doesn't work for you is that the installation procedure (which you haven't run) converts all the provided Python 2 code so that it works on Python 3. It is not that someone didn't bother to check the code for basic syntax errors!
If you are trying to use Django, though, Python 3 is definitely the wrong choice - the installation instructions clearly say you need to be using Python 2.5 to 2.7: https://docs.djangoproject.com/en/1.4/intro/install/
Since you are new to Python, you should try to walk before you run, and go with the tried and tested path - which is Python 2.7 for Django. Ignoring installation instructions and requirements will only slow you down and make life hard.