Ok, I have processed most of the Cython/Include/python/*.pxd files.
Seems these were mechanically derived from docs? Because some
of the bugs in the docs are also in these files. Not sure what you
would like to do so I’ll ask here before doing github issues.
1. Its not all there. I couldn’t find the API for generators for example.
If the API is extracted from the docs the script could be run again.
2. pyport is plain wrong. It contains conflicting C typedefs.
3. Some of the files describe extension modules (datetime, array)
rather than the core API.
4. ../cython/Cython/Includes/cpython/weakref.pxd: bint
PyWeakref_CheckProxy(ob)
ob should be PyObject*
there’s a couple more (maybe in ref as well).
====
Python keeps changing the API. Its not clear exactly which version is
represented.
I have the same issue, i have no idea at the moment how to deal with it.
=====
I’m thinking to do some test runs of Cython on some Python code. I’ll be
running Cython as a translator directly from the command line.
Now when I built Cython before with “make” I saw lots of “python2.7” in the
output which is not what I want to process.
My Felix test code is executing plain C code bound againt a brew installed
Python run time library, the meta data required to link that is this:
Name: Pycore
Description: Macosx bindings to Python shared run time library core.
cflags:
-I/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/include/python3.6m
includes: '"Python.h"'
provides_dlib:
-L/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib
-lpython3.6m
provides_slib:
-L/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib
-lpython3.6m
And I can run the corresponding Python:
~/felix>/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/bin/python3.6m
Python 3.6.5 (default, Apr 25 2018, 14:26:36)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
And here is a test program written in Felix that uses the bindings:
println$ Py_GetVersion();
Py_Initialize();
var x : PyObject = PyLong_FromLong (42);
var y : long = PyLong_AsLong (x);
println$ PyLong_Check x;
println$ y;
println$ (f"%x" header_version);
and here’s the output:
~/felix>flx pycheck.flx
3.6.5 (default, Apr 25 2018, 14:26:36)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
true
42
30605f0
Note this code is generating a shared library BUT it is being run by Felix,
it is NOT being loaded as a module under Python. I will check that works
next.
So I’m showing all this because I would now like to run Cython on a little
test script using the same run time library as above, and perhaps the
same Python interpreter. I have too many Python’s installed all over the
place to really know what’s what.
So I would appreciate step by step instructions on how to build and use
Cython so it uses and generates code binding to the exact same
Python/run time as above. I guess I’ll test some kind of hello world
program.
===
I’m expecting that on OSX and Windows, CPython extensions will work,
but on Linux they will fail. This is because last time I looked, extensions
were built assuming a flat linker namespace with the API provided by the
Python executable. Indeed, I’m not sure if you can even get a Python
executable on Linux that isn’t statically linked to the run time.
However the shared library extensions I generate will always be linked
against a shared library. My build tech does not permit flat namespaces
for dynamic linkage. I know you CAN get Python run time as a shared
library on Debian based systems, but I don’t think you can get
a stub Python executable. Its essential that all the global data is held
by the library not the executable, otherwise it won’t be shared by
libraries that link to it.
However stuff may have changed recently. I can of course build Python
from source myself and hack it to build correctly, its not that hard,
but Felix clients will not be able to do that.
This issue will impact Cython uses exactly the same way for the same reason.
—
John Skaller
skal...@internode.on.net
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
