FX Coudert added the comment:
This bug is present in all versions since the 3.6 branch at least, but was only
triggered when users' readline settings explicitly enabled bracketed-paste.
Previous reports: https://bugs.python.org/issue32019 and
https://bugs.python.org/issue39820 Longer
FX Coudert added the comment:
Our messages crossed, thanks Ned for the help. Hopefully we'll be solving this
in a way that benefit most users.
--
___
Python tracker
<https://bugs.python.org/issue42
FX Coudert added the comment:
But we can override with --with-tcltk-includes and --with-tcltk-libs
I've opened a pull request for Homebrew to switch to recent tcl-tk:
https://github.com/Homebrew/homebrew-core/pull/67378
--
___
Python tracker
FX Coudert added the comment:
After checking, I can see the code in cpython's setup.py is still there.
detect_tkinter_darwin will prefer the system's version over anything we can
specific in our cflags or ldflags. This seems contrary to the advice above not
to use macOS system Tcl/Tk
FX Coudert added the comment:
Hi Ned,
FX from Homebrew here. One of the reasons we a couple of years ago to stick
with macOS system tcl-tk was that cpython's configure does not currently allow
to build against our tcl-tk, which is not a framework but a simple Unix-style
library build. We
FX Coudert added the comment:
Reported to Apple as FB8945560
--
___
Python tracker
<https://bugs.python.org/issue42480>
___
___
Python-bugs-list mailin
FX Coudert added the comment:
Hi, Homebrew developer here, we're seeing this with macOS 11.1 and I think it's
not a python issue but an Apple's Tcl/Tk issue. The backtrace I have is:
0 libsystem_kernel.dylib 0x7fff2031f462 __pthread_kill + 10
1 libsystem_pthread.dylib
FX Coudert added the comment:
> having "11.0" as the version a number is ship that has sailed
I understand. What is needed is consistency and predictability.
Now, the next minor releases will be 11.0.1 (that has shipped already), 11.1.0
(will ship soon), then either 11.1.1
FX Coudert added the comment:
"It has always resulted in a string value": only MACOSX_DEPLOYMENT_TARGET
always took the form of a non-integer. The code for sysconfig.get_config_var()
has a pretty clear intent: it will try to cast its return value to an int.
I don't have a stro
FX Coudert added the comment:
Actually, I can find some distribution of Python where the minor version is
returned, for example on Apple macOS 10.15.4:
/usr/bin/python3 -c 'import distutils.util;
print(distutils.util.get_platform())'
macosx-10.14.6-x86_64
Therefore maybe I misunderstand
FX Coudert added the comment:
What I think should be the logical solution to this bug:
make distutils.util.get_platform() return "macosx-11-x86_64" on all Big Sur
(macOS 11.x.y) versions, independent of the minor OS version.
However, if the Python developers decide that t
New submission from FX Coudert :
On macOS Big Sur (11.y.z), the return value of distutils.util.get_platform()
records in some cases the minor version of OS. For example:
- with a Python 3.9 built on macOS 10.0.1, distutils.util.get_platform() will
return macosx-11.0-x86_64
- with a Python
Change by FX Coudert :
--
keywords: +patch
pull_requests: +22437
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23556
___
Python tracker
<https://bugs.python.org/issu
New submission from FX Coudert :
With macOS Big Sur (11.y.z), the major version is 11 (instead of the earlier
10.15, 10.14, etc). Therefore, MACOSX_DEPLOYMENT_TARGET=11 has become a valid
setting. It is accepted by system tools:
$ MACOSX_DEPLOYMENT_TARGET=11 clang a.c && e
14 matches
Mail list logo
