I am trying to compile Python 3 on Centos7 and I am getting "ModuleNotFoundError: No module named '_ctypes'"
Context: Centos7 uses Python 2.7.5 for its routines, so it is need to leave original Python 2.7.5 untouched. Python 3 (in case 3.7.3) needs to be compiled for alternate install.
I am downloading source from python.org and using verbatin instructions from https://danieleriksson.net/2017/02/08/how-to-install-latest-python-on-cento…. I just changed version to 3.7.3.
The compilation of …
[View More]3.7.3, 3.7.2, 3.7.1 fails with following msgs:
# make && make altinstall
.
.
File "/root/Python-3.7.3/Lib/ensurepip/__init__.py", line 27, in _run_pip
import pip._internal
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/__init__.py", line 40, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/cli/autocompletion.py", line 8, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/cli/main_parser.py", line 12, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/commands/__init__.py", line 6, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/commands/completion.py", line 6, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/cli/base_command.py", line 20, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/download.py", line 37, in <module>
File "/tmp/tmp8h0mvcgm/pip-19.0.3-py2.py3-none-any.whl/pip/_internal/utils/glibc.py", line 3, in <module>
File "/root/Python-3.7.3/Lib/ctypes/__init__.py", line 7, in <module>
from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
make: *** [altinstall] Error 1
=================================================================
But Python 3.6.8 compiles OK:
changing mode of /usr/local/bin/idle3.6 to 755
changing mode of /usr/local/bin/2to3-3.6 to 755
changing mode of /usr/local/bin/pyvenv-3.6 to 755
rm /usr/local/lib/python3.6/lib-dynload/_sysconfigdata_m_linux_x86_64-linux-gnu.py
rm -r /usr/local/lib/python3.6/lib-dynload/__pycache__
/bin/install -c -m 644 ./Misc/python.man \
/usr/local/share/man/man1/python3.6.1
if test "xupgrade" != "xno" ; then \
case upgrade in \
upgrade) ensurepip="--altinstall --upgrade" ;; \
install|*) ensurepip="--altinstall" ;; \
esac; \
LD_LIBRARY_PATH=/root/Python-3.6.8 ./python -E -m ensurepip \
$ensurepip --root=/ ; \
fi
Looking in links: /tmp/tmpwmo1o05a
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-18.1 setuptools-40.6.2
Thanks for your attention.
Carlos
[View Less]
Hi, all.
Some functions in cpython are private. These APIs
are called from only python executable or DLL.
They are not called even from extension modules in stdlib.
In this time, I want to keep _PyObject_GetMethod private.
https://github.com/python/cpython/pull/14015#discussion_r293351734
As far as I know, it is used to expose the function from DLL user on Windows.
So I think when the private function is not intended to be
called from outside of DLL, it should not use PyAPI_FUNC.
Am I …
[View More]collect?
Currently, many private APIs uses `PyAPI_FUNC()`.
Is there any downside about having much unnecessary exported functions?
(e.g. slower calling invention is used, bothering link time
optimization, LoadLibrary get slower, etc...)
Regards,
--
Inada Naoki <songofacandy(a)gmail.com>
[View Less]
Hey Python developers,
I just published the initial release of PyOxidizer - a utility for
producing self-contained, potentially single file executable Python
applications. You can read more about it at
https://gregoryszorc.com/blog/2019/06/24/building-standalone-python-applica…
I wanted to draw this list's attention to it because I think PyOxidizer
could have significant implications for the Python community. And the 2nd
to final section in the blog post is of particular relevance to CPython'…
[View More]s
development team.
I want to state explicitly that I would prefer to work with the Python
community in whatever appropriate capacity is needed to advance the state
of Python application distribution. (I have already participated in
discussions about PEP 587.) PyOxidizer is still young and there's a long
way to go. But I would love to e.g. implement PyOxidizer with an eye
towards incorporation in official Python packaging tools a few years down
the road. I'm not too familiar with the various day-to-day happenings of
Python and Python Packaging. But if you steer me in the right direction, I
could start getting involved...
I hope you like PyOxidizer!
Gregory Szorc
gregory.szorc(a)gmail.com
[View Less]