Mailman 3 July 2019 - Python-Dev

3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)
by csotto＠uol.com.br July 2, 2019

July 2, 2019

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 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

4 4

PyAPI_FUNC() is needed to private APIs?
by Inada Naoki July 2, 2019

July 2, 2019

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 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>

6 12

Building Standalone Python Applications with PyOxidizer
by Gregory Szorc July 1, 2019

July 1, 2019

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'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

3 2