[issue44492] Building a C extension on Big Sur and SDK v10.15 fails
Phil Thompson added the comment: Is this likely to be fixed for v3.10? At the very least a wheel should have the correct platform tag. -- ___ Python tracker <https://bugs.python.org/issue44492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44492] Building a C extension on Big Sur and SDK v10.15 fails
Phil Thompson added the comment: Another aspect of this is when building a Python v3.10 C extension on macOS v10.15 (Catalina) with SDK 10.15, the wheel has the 'universal2' platform tag when it actually only contains an x86_64 implementation. -- ___ Python tracker <https://bugs.python.org/issue44492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44492] Building a C extension on Big Sur and SDK v10.15 fails
New submission from Phil Thompson : I am running macOS v11 (Big Sur) and using Xcode v12.1 (because this is the latest that includes SDK v10.15 rather than v11) to build a C extension. I'm using the older SDK because of 3rd party libraries that are not tested against the newer SDK. This version of Xcode/SDK does not support universal2 binaries. However because _supports_arm64_builds() in _osx_support only tests the macOS version and not the SDK version it returns True which means that distutils does not call compiler_fixup() to remove the '-arch arm64'. The compilation then fails. Should this work, or does Python v3.10 require SDK v11? -- components: Distutils messages: 396377 nosy: dstufft, eric.araujo, philthompson10 priority: normal severity: normal status: open title: Building a C extension on Big Sur and SDK v10.15 fails type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
Phil Thompson added the comment: >> Which is why I protect the initialisation with #if PY_VERSION_HEX < > 0x0309 > > It is your specific case. We can not assume people do it, or even you > never forget it. So this is not the "right thing" we can recommend to > all users. > > Once you or other people suppress the deprecation warning and forget > the protect, compatibility issue happen again. Why such dangerous > option is needed? If I fail to protect against using a feature when it is no longer present then it's a bug in my code and it won't compile. Providing a deprecation warning gives me some notice that my code needs to be changed. That is helpful but not strictly necessary as I will soon find out when testing against the new version. There is nothing "dangerous" here. -- ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
Phil Thompson added the comment: On 19/07/2019 11:37, Jeroen Demeyer wrote: > Jeroen Demeyer added the comment: > >> We have some reserved/deprecated/unused fields. Setting 0 to them >> makes forward incompatible code. > > Good point. tp_print is removed in 3.9 Which is why I protect the initialisation with #if PY_VERSION_HEX < 0x0309 As far as I can see this is the "right thing" to do. However doing the "right thing" means I cannot avoid warnings without resorting to compiler-specific build system changes. With the change I am asking for I can suppress the warning (because I have explicitly dealt with the issue) in the code itself without affecting the rest of the system. -- ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
Phil Thompson added the comment: I am not "touching" tp_print. I am simply defining it as 0 to avoid the missing initialiser warning. My point is that it should be possible to write code that doesn't trigger warnings (whether or not you suppress them). -- ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37588] Py_DEPRECATED and unavoidable warnings
New submission from Phil Thompson : I have a number of static PyTypeObject declarations. In order to avoid compiler warnings about missing field initialisers I always provide explicit 0 values for unused fields (protected by #if PY_HEX_VERSION >= ...). However with v3.8b2 this triggers new warnings from Py_DEPRECATED because of the initialiser for tp_print. I would like some way of locally suppressing Py_DEPRECATED. The attached trivial patch would do this by allowing me to define a null Py_DEPRECATED before including Python.h. -- components: Interpreter Core files: pyport.h.diff keywords: patch messages: 347848 nosy: philthompson10 priority: normal severity: normal status: open title: Py_DEPRECATED and unavoidable warnings type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48478/pyport.h.diff ___ Python tracker <https://bugs.python.org/issue37588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37356] Name of 64-bit OpenSSL v1.1.1 DLLs
Phil Thompson added the comment: A clarification... It seems the suffix is added when configured as VC-WIN64A but omitted when configured as VC-WIN64A-masm. ...still not a Python problem. -- ___ Python tracker <https://bugs.python.org/issue37356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37356] Name of 64-bit OpenSSL v1.1.1 DLLs
Phil Thompson added the comment: I think I was incorrect in saying the suffix was the default when building v1.1.1 from source, so any problem I have (trying to share the DLL with different pre-built packages) is not a Python problem. Sorry for the noise. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37356] Name of 64-bit OpenSSL v1.1.1 DLLs
New submission from Phil Thompson : In the 3.8b1 64-bit Windows installer the names of the OpenSSL DLLs do not have the -x64 suffix which seems to be the convention (and is the default when building OpenSSL from source). The convention is followed in the 3.7.0 to 3.7.3 installers. I haven't yet checked the 3.7.4rc1 installer. -- assignee: christian.heimes components: Installation, SSL, Windows messages: 346172 nosy: christian.heimes, paul.moore, philthompson10, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Name of 64-bit OpenSSL v1.1.1 DLLs versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue37356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32141] configure with Spaces in Directory Name on macOS
New submission from Phil Thompson <p...@riverbankcomputing.com>: When configure searches for a C compiler on macOS it fails to handle spaces in directory name on PATH. The fix is to enclose $as_dir in quotes. -- components: Build messages: 307004 nosy: philthompson10 priority: normal severity: normal status: open title: configure with Spaces in Directory Name on macOS type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27146] posixmodule.c needs stdio.h
New submission from Phil Thompson: posixmodule.c needs to #include to get the declaration of ctermid(). On most platforms this happens as a side effect of including other .h files but does not on Android. -- components: Library (Lib) messages: 266561 nosy: philthompson10 priority: normal severity: normal status: open title: posixmodule.c needs stdio.h type: compile error versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26007] Request for Support for Embedding the Standard Library in an Executable
Phil Thompson added the comment: At the moment my importer does the same as zipimport and gets added to sys.path_hooks rather than sys.meta_path. While waiting for the PEP, how about a table of (externally modifiable) importer installers that is worked through where _PyImportZip_Init() is currently called? By default _PyImportZip_Init() will be the only entry. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26007] Request for Support for Embedding the Standard Library in an Executable
Phil Thompson added the comment: Understood, but the only promise here is to call a function (with no arguments, and returning no result). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26007] Request for Support for Embedding the Standard Library in an Executable
Phil Thompson added the comment: I don't see why it would be hard to test. The change suggested wouldn't alter the default behaviour at all. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26007] Request for Support for Embedding the Standard Library in an Executable
Phil Thompson added the comment: Yes, preventing the filesystem being used for imports would be another way of expressing the issue. Regarding the title I specifically didn't want to suggest a solution as I'm not expert enough to know what the best solution might be. If, as Paul implies, it should be possible to run the standard library from a zipfile then it suggests that this should actually be a bug report. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26007] Request for Support for Embedding the Standard Library in an Executable
Phil Thompson added the comment: The problem is the import of the encodings module in _PyCodecRegistry_Init(). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26007] Request for Support for Embedding the Standard Library in an Executable
New submission from Phil Thompson: The use case is a packaging tool that can create a single executable for a Python application. Like similar tools it embeds frozen Python code (including the standard library) and is linked (often statically) against the interpreter library. Executables are usually configured so that they cannot import packages from the filesystem. They can only import packages embedded in the executable. This is done directly, ie. the package is not written out to the filesystem and imported from there. This is done by a specially written importer. The importer is installed by adding it to sys.path_hooks. However this must be done early on in the bootstrap process so that the parts of the standard library that are implemented as Python packages can be found by the installer. For example, the point at which the zipimport importer is added to sys.path_hooks is too late. Currently a modified version of bootstrap_external.py is embedded in the executable which updates sys.path_hooks at the end of the _install() function. What I would like is some way to avoid having to modify bootstrap_external.py to install a new importer sufficiently early in the bootstrap process to allow it to import the standard library. -- components: Interpreter Core messages: 257464 nosy: philthompson10 priority: normal severity: normal status: open title: Request for Support for Embedding the Standard Library in an Executable type: enhancement versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26007> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO
New submission from Phil Thompson p...@riverbankcomputing.com: The old unaccelerated ETree XMLParser accepts input from a io.StringIO, but the accelerated version does not. Any code that relies on this is broken by Python v3.3. -- components: XML messages: 155301 nosy: philthompson10 priority: normal severity: normal status: open title: Accelerated ETree XMLParser cannot handle io.StringIO type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14246 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14246] Accelerated ETree XMLParser cannot handle io.StringIO
Phil Thompson p...@riverbankcomputing.com added the comment:
This variation of your test doesn't...
---
import io
from xml.etree.ElementTree import parse
stream = io.StringIO()
stream.write('''?xml version=1.0?
site
/site
''')
stream.seek(0)
parsed = parse(stream)
print(parsed)
---
Phil
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14246
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10681] PySlice_GetIndices() signature changed
New submission from Phil Thompson p...@riverbankcomputing.com: In Python v3.2b1 the type of the first argument of PySlice_GetIndices() and PySlice_GetIndicesEx() has changed from PySliceObject* to PyObject*. The documentation does not reflect this change. Which is correct, the source code or the documentation? -- assignee: d...@python components: Documentation, Interpreter Core messages: 123809 nosy: Phil.Thompson, d...@python priority: normal severity: normal status: open title: PySlice_GetIndices() signature changed type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10681 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10681] PySlice_GetIndices() signature changed
Phil Thompson p...@riverbankcomputing.com added the comment: You might want to add a Changed in Python v3.2 because as it is an incompatible change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10681 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10681] PySlice_GetIndices() signature changed
Phil Thompson p...@riverbankcomputing.com added the comment: It's source level incompatible - my extension modules compiled fine with v3.2a but failed with v3.2b1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10681 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1337876] Inconsistent use of buffer interface in string and unicode
Phil Thompson p...@riverbankcomputing.com added the comment: Yes I can update the patch, but it might be a while before I get the time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1337876 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
