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/issue44
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 impl
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.
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 recommen
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
Wh
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 yo
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
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.
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: -> no
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&#
New submission from Phil Thompson :
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
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
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
<http://bugs.python.org/issue26
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
<http://bugs.python.o
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
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 i
Phil Thompson added the comment:
The problem is the import of the encodings module in _PyCodecRegistry_Init().
--
___
Python tracker
<http://bugs.python.org/issue26
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
Phil Thompson added the comment:
This variation of your test doesn't...
---
import io
from xml.etree.ElementTree import parse
stream = io.StringIO()
stream.write('''
''')
stream.seek(0)
p
New submission from Phil Thompson :
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
Phil Thompson added the comment:
It's source level incompatible - my extension modules compiled fine with v3.2a
but failed with v3.2b1.
--
___
Python tracker
<http://bugs.python.org/is
Phil Thompson added the comment:
You might want to add a "Changed in Python v3.2" because as it is an
incompatible change.
--
___
Python tracker
<http://bugs.python.o
New submission from Phil Thompson :
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
Phil Thompson added the comment:
Yes I can update the patch, but it might be a while before I get the time.
--
___
Python tracker
<http://bugs.python.org/issue1337
24 matches
Mail list logo
