[issue47179] pymalloc should align to max_align_t
Ronald Oussoren added the comment: > If we want to respect sizeof(max_align_t) alignment, we can compute > sizeof(max_align_t) in configure and uses the result in obmalloc.c. I expect > that it's either 16 or 32, so we can maybe just hardcode ALIGNMENT_SHIFT > using something like: "if == 32 ... #elif == 16 ... #else #error ...". This should be "alignof(max_align_t)" instead of "sizeof(...)". The size itself is not relevant. BTW, on macOS/arm64 alignof(max_align_t) is 8, not 16 (as the code seems to expect given the pointer size). This is harmless of course. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue47179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47240] Python 3.x built for ppc+ppc64 errs on: No module named 'msvcrt', '_posixsubprocess'
Ronald Oussoren added the comment: The problem you should look into is why the _posixsubprocess doesn't build, the message about msvcrt is a red herring due to the way subprocess.py is structured. Also compare the pyconfig.h files created for the two single architecture builds, maybe there are differences in detected features for the two architectures (other than CPU differences, there's a pymacconfig.h files that sets the correct values for sizes of basic types). That said, I won't be debugging this issue myself. MacOS on PowerPC is by now a thing of the past and IIRC the last time I had access to a 64-bit PPC machine was before GUI code would run properly in PPC64 mode. -- ___ Python tracker <https://bugs.python.org/issue47240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47124] explore hashlib use of the Apple CryptoKit macOS
Ronald Oussoren added the comment: SecDigestTransformCreate() is probably a relevant API to look into, this seems to be supported from 10.7 until now. A major disadvantage for us of this API is that it is a CoreFoundation API and because of that is problematic in pre-forking scenario's (that is, call in a child proces that's the result of fork-without-exec) because most if not all CoreFoundation types are not safe to use in these scenario's. Apple also has an older crypto API, but that has been deprecated for a long time and should not be used. -- ___ Python tracker <https://bugs.python.org/issue47124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47124] explore hashlib use of the Apple CryptoKit macOS
Ronald Oussoren added the comment: A "problem" with CryptoKit is that it is a swift-only framework, which makes using those APIs harder from C code (not impossible). The older Security framework also contains crypto APIs, but seems to have less support for modern algorithms (e.g. no support for Curve25519). TBH I'm not sure if it is worthwhile to look into this in CPython, or that we should rely on OpenSSL for any integration (similar to Christian Heimes opinion on using the system keystore in the ssl module). -- ___ Python tracker <https://bugs.python.org/issue47124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47064] thread QOS attribute on macOS
Ronald Oussoren added the comment: I agree. I'm working on a PR to expose this platform specific functionality in the threading module. It would have been nice if other platforms had similar functionality, but they don't. Emulating the API is possible, but a project in its own right and something that will result in a lot of discussion. IMHO this is something we shouldn't do within the CPython project. -- ___ Python tracker <https://bugs.python.org/issue47064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47064] thread QOS attribute on macOS
Ronald Oussoren added the comment: > For example, using a priority policy that actually uses QOS attribute :) How would that look? The QOS class is already a high level interface that affects a number of low-level polices. The classes are comprehensively documented in sys/qos.h. In short (my rephrasing and summary of the documentation in sys/qos.h): * QOS_CLASS_INTERACTIVE This QOS class indicates that the work on the thread is interactive with the user. * QOS_CLASS_USER_INITIATED This QOS class indicates that work was initiated by the user and the user is likely waiting for the result. * QOS_CLASS_DEFAULT Default QOS class. * QOS_CLASS_UTILITY This QOS class indicates that work may or may not be initiated by the user and the user is unlikely to be waiting for the result. * QOS_CLASS_BACKGROUND This QOS class indicates that the work on this thread was not initiated by the user, and the user is not waiting for a result. Having a python policy object instead of these fixed classes might be more flexible, but tuning those is anything but trivial and exposing such a low-level interface directly to users would likely be too complex for most use cases. I'd be more interested in trying to implement the same interface on other platforms using the low-level APIs for those platforms (but won't do that, all my linux code is running on servers and uses tooling enternal to the application to control resource usage). The biggest problem with these predefined classes is that they are pretty much targeted toward end-user systems and not servers, but that's the target of macOS anyway. BTW. I'm working on a PR. -- ___ Python tracker <https://bugs.python.org/issue47064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47064] thread QOS attribute on macOS
New submission from Ronald Oussoren : Arm based Mac systems have several types of cores: performance cores and efficiency cores. The system has no way to directly specify which core a particular proces or thread uses, but programs can use an API for setting the QOS class of a thread that will influence which type of core a proces is scheduled on. The primary use case for this would be to select a lower QOS class for background tasks to ensure that those minimally impact interactive code. It would be nice to expose this functionality in Python. One way to do this is to expose two or three new APIs: 0. Expose an enum.IntEnum on macOS for the various QOS classes 1. An API for setting the QOS class of a particular thread (which could also be used to change that class for the main thread), for example a read/write property ``threading.Thread.qos_class`` 2. A new keyword argument ``qos_class`` to ``threading.Thread.__init__()`` 3. Optional: an API for setting changing the default value for that new keyword argument The new API would only exist on macOS. One consideration: This is a platform specific option, in my limited research I haven't found an easy way to accomplish similar results on Linux or Windows. Background information: https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon -- components: Interpreter Core, macOS messages: 415538 nosy: ned.deily, ronaldoussoren priority: normal severity: normal status: open title: thread QOS attribute on macOS type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46996] Drop support of Tcl/Tk older than 8.5.12
Ronald Oussoren added the comment: Terry: tkinter on macOS already effectively does not support Tk 8.5, or basically anything bug the latest 8.6.x release. That's because older versions have too many bugs that affect Python users, which mostly show up on our tracker as bug reports about IDLE. Because of this we generally close issues that mention using tkinter with 8.5 on macOS unless the problem can be reproduced using 8.6 as well (using the installer on python.org). -- ___ Python tracker <https://bugs.python.org/issue46996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] getpath problems with framework build
Change by Ronald Oussoren : -- keywords: +patch pull_requests: +30047 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31958 ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46996] Drop support of Tcl/Tk older than 8.5.12
Ronald Oussoren added the comment: One consideration is support for older LTS distributions of Linux, RHEL/Centos 7 appears to ship with Tcl/Tk 8.5. The system install of Tcl/Tk on macOS is also 8.5, but that variant has too many bugs to try to support it. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] getpath problems with framework build
Ronald Oussoren added the comment: venv requiring site isn't really a problem, although it is a bit weird that sys.prefix changes when using the -S flag. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] getpath problems with framework build
Ronald Oussoren added the comment: > However, it's the site.py module that actually updates sys.prefix for the > venv. So you may just be inspecting at the wrong point? Or possibly it's in a > codepath that doesn't run on macOS because *previously* it was being set > correctly in getpath instead of being deferred until later? I just noticed the same. Is this intentional? This means that "python -S" doesn't work with a virtual environment. I also noticed that site.py's venv support contains some special code for framework builds that shouldn't be necessary. But I guess that's something for some other tickets. I'm pretty sure I now just have to clean up my patch and create a PR from it. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46923] Implement stack overflow protection for supported platforms
Ronald Oussoren added the comment: issue33955 is an older issue about implementing the current functionality for this on macOS, which has an API for querying stack limits. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] getpath problems with framework build
Ronald Oussoren added the comment:
I've updated the title to better reflect the actual problem.
An update on the current state of this issue:
I haven't looked at the code for a couple of days because because I got stuck.
With a fresh mind I've continued debugging and noticed that I'm looking in the
wrong place...
I've added some warn() calls to the end of getpath.py to print the updated
variables:
``
warn(f"END prefix: {config['prefix']}")
warn(f"END exec_prefix: {config['exec_prefix']}")
warn(f"END base_prefix: {config['base_prefix']}")
warn(f"END base_exec_prefix: {config['base_exec_prefix']}")
```
When I use this build with a framework build with and alternate name
(``--enable-framework --with-framework-name=DebugPython``) and then create a
venv in ``X/workenv`` I get expected output when I use the python in that venv:
```
$ X/workenv/bin/python -c 'import sys; print(f"ACTUAL prefix:
{sys.prefix}\nACTUAL base_prefix: {sys.base_prefix}")'
END prefix: /Library/Frameworks/DebugPython.framework/Versions/3.11
END exec_prefix: /Library/Frameworks/DebugPython.framework/Versions/3.11
END base_prefix: /Library/Frameworks/DebugPython.framework/Versions/3.11
END base_exec_prefix: /Library/Frameworks/DebugPython.framework/Versions/3.11
ACTUAL prefix: /Users/ronald/Projects/Forks/cpython/build/X/workenv
ACTUAL base_prefix: /Library/Frameworks/DebugPython.framework/Versions/3.11
```
Note how "ACTUAL prefix" is different from "END prefix".
The weird bit is that the only reference to 'workenv' (the name of the venv) is
in the value of config["executable"].
I'm now convinced that sys.prefix is set after ``_PyConfig_InitPathConfig``,
I've added some more debug prints around the call to ``_PyConfig_FromDict`` in
``_PyConfig_InitPathConfig`` and that prints:
```
before reconfig: config->prefix = (null)
before reconfig: sys.prefix = (not set)
after reconfig: config->prefix =
/Library/Frameworks/DebugPython.framework/Versions/3.11
after reconfig: sys.prefix = (not set)
```
I have no idea where sys.prefix get's initialised though, the configuration
initialisation code could use some documentation.
I've attached a new version of my patch, still work in progress and including
debug code. Definitely not ready for merging.
In short: my patch (v3) seems to work, but I have no idea why.
--
title: venv does not create "python" link in python 3.11 -> getpath problems
with framework build
Added file: https://bugs.python.org/file50669/issue-46890-v3.txt
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
WITH_NEXT_FRAMEWORK is a compile time option, I've added it to globals in
values like PREFIX are added. That way the python code can behave differently
for framework builds (which appears to be needed).
There are two big problems with my patches:
- Calculation of sys.prefix doesn't work in test_venv_framework_macos, but
somehow works with a real installation. I haven't managed to track down the
difference yet.
- Calculation for test_framework_macos appears to be ok on first glance, but
adding "/Library/lib/python9.8.zip" as a known file shows that the code to look
for the stdlib is misbehaving.
The latter appears to be a wider problem, if I add a test case based on
test_normal_posix with PREFIX=/opt/python9.8 the getpath code looks for
/opt/lib/python98.zip and uses that when found.
Test case for this (test passed when
``ns.add_known_file("/opt/lib/python98.zip")`` is commented out:
def test_normal_posix_in_opt(self):
"""Test a 'standard' install layout on *nix
This uses '/opt/python9.8' as PREFIX
"""
ns = MockPosixNamespace(
PREFIX="/opt/python9.8",
argv0="python",
ENV_PATH="/usr/bin:/opt/python9.8/bin",
)
ns.add_known_xfile("/opt/python9.8/bin/python")
ns.add_known_file("/opt/python9.8/lib/python9.8/os.py")
ns.add_known_dir("/opt/python9.8/lib/python9.8/lib-dynload")
# This shouldn't matter:
ns.add_known_file("/opt/lib/python98.zip")
expected = dict(
executable="/opt/python9.8/bin/python",
base_executable="/opt/python9.8/bin/python",
prefix="/opt/python9.8",
exec_prefix="/opt/python9.8",
module_search_paths_set=1,
module_search_paths=[
"/opt/python9.8/lib/python98.zip",
"/opt/python9.8/lib/python9.8",
"/opt/python9.8/lib/python9.8/lib-dynload",
],
)
actual = getpath(ns, expected)
self.assertEqual(expected, actual)
This could be problematic, adding a suitably named file outside of $PREFIX
breaks the python installation. I haven't checked this with an unchanged
getpath.py yet, but I shouldn't have made any changes that affect a
non-framework install.
--
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: I've attached a new patch file with some more tweaks, including the additional test case from msg414665. I've pretty sure that the changes to getpath.py are slightly worse in the new version, but aren't fully correct in the initial version as well (see my previous message about searching outside of the framework). I may return to this later when I have time to try to really understand what's going on and compare the logic with the previous C code (especially for framework builds). But for now I'm giving up. -- Added file: https://bugs.python.org/file50662/issue-46890-v2.txt ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
I'm now in the fun position where the code works, but the test test_getpath.py
fails.
The test case below tries to test a venv in a framework build, but somehow
fails to calculate prefix and exec_prefix correctly. The calculation does work
when using a framework build with my patch...
def test_venv_framework_macos(self):
"""Test a venv layout on macOS using a framework build
"""
venv_path = "/tmp/workdir/venv"
ns = MockPosixNamespace(
os_name="darwin",
argv0="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
WITH_NEXT_FRAMEWORK=1,
PREFIX="/Library/Frameworks/Python.framework/Versions/9.8",
EXEC_PREFIX="/Library/Frameworks/Python.framework/Versions/9.8",
ENV___PYVENV_LAUNCHER__=f"{venv_path}/bin/python",
real_executable="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
library="/Library/Frameworks/Python.framework/Versions/9.8/Python",
)
ns.add_known_dir(venv_path)
ns.add_known_xfile(f"{venv_path}/bin/python")
ns.add_known_dir(f"{venv_path}/lib/python9.8")
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python")
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8")
ns.add_known_dir("/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload")
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/os.py")
ns.add_known_file(f"{venv_path}/pyvenv.cfg", [
"home = /Library/Frameworks/Python.framework/Versions/9.8/bin"
])
expected = dict(
executable=f"{venv_path}/bin/python",
prefix=venv_path,
exec_prefix=venv_path,
base_executable="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
base_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
base_exec_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
module_search_paths_set=1,
module_search_paths=[
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip",
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8",
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload",
],
)
actual = getpath(ns, expected)
self.assertEqual(expected, actual)
--
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: This is also dodgy: test_framework_macos (test.test_getpath.MockGetPathTests) ... Read link from /Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python Check if /Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Modules/Setup.local is a file Check if /Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip is a file Check if /Library/Frameworks/Python.framework/Versions/lib/python98.zip is a file Check if /Library/Frameworks/Python.framework/lib/python98.zip is a file Check if /Library/Frameworks/lib/python98.zip is a file Check if /Library/lib/python98.zip is a file Check if /Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/os.py is a file Check if /Library/Frameworks/Python.framework/Versions/9.8/bin/lib/python9.8/lib-dynload is a dir Check if /Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload is a dir Note how the code checks for the standard library outside of the framework itself. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: I have a patch that seems to do the right thing. It required adding WITH_NEXT_FRAMEWORK to the globals when evaluating getpath.py to detect this scenario. There probably should be more tests, in particular a test for a virtual environment using a framework install as I had to adjust my patch after manually testing a virtual environment. I'm not entirely happy with the patch yet, the change to getpath.py is basically the minimal change I could get away with without grokking the entire file. There's no PR yet as I've broken my fork of cpython, fixing that is next up on the list. BTW. Is there a way to find the values that get put into the globals dict for getpath.py without using a debugger (either a real one or the printf variant)? -- Added file: https://bugs.python.org/file50660/issue-46890.txt ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)
Ronald Oussoren added the comment: Your PR fixed the issue for me. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46928] type.__qualname__ ignores module name in tp_name for static types
Ronald Oussoren added the comment: You're right. I was sure that __qualname__ included the module name, but PEP 3155 is clear about actual semantics. Sorry about the noise. -- resolution: -> not a bug stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46928] type.__qualname__ ignores module name in tp_name for static types
New submission from Ronald Oussoren :
In a static type when the "tp_name" is set to a fully qualified name (such as
"my.package.TypeName") the "__qualname__" returns the unqualified name
("TypeName") instead of the fully qualified name.
The type's ``__name__`` and ``__module__`` have the expected value.
This is IMHO a bug in the implementation of type_qualname in
Objects/typeobject.c.
Note that setting ``__qualname__`` in the types's ``__dict__`` doesn't work,
that value is ignored.
--
components: Interpreter Core
messages: 414574
nosy: ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: type.__qualname__ ignores module name in tp_name for static types
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46928>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
Ronald Oussoren added the comment: This is probably not a bug in python, but a change in system behaviour. In particular, I've used the lsof command to check the open files for the syslogd proces on a macOS 10.13 and 12.2 system. On the former syslogd has /var/run/syslog open, on the latter it doesn't. The feature to listen on this socket has been removed entirely, the 12.2 system no longer lists a "-bsd_in" option for syslogd in the manual page whereas it is both available and enabled by default on 10.13. It might be possible to change the SyslogHandler to optionally use the syslog module to log, but I'm not sure it is worth doing this and that would definitely be a new feature. -- resolution: -> third party type: -> behavior ___ Python tracker <https://bugs.python.org/issue46914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)
Ronald Oussoren added the comment: A hard crash seems wrong to me, and I'm not convinced yet that checking that the type of the attribute name is exactly string is correct. Found while debugging a crash in PyObjC's testsuite, PyObjC uses a subclass of str to represent Objective-C strings. Using such instances works fine in practice, but causes a crash in a --with-pydebug build due to this assertion. -- ___ Python tracker <https://bugs.python.org/issue46903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46903] Crash when setting attribute with string subclass as the name (--with-pydebug)
New submission from Ronald Oussoren :
The script below fails with an assertion error with python 3.11a5+ (current
trunk) when build with --with-pydebug:
# BEGIN OF FILE
class String(str):
__slots__ = ()
name = String("hello")
class Bag:
pass
o = Bag()
setattr(o, name, 42)
# END OF FILE
Error output:
% /tmp/py311/bin/python3 -Xdev str.py
(master)pyobjc-8
Assertion failed: (PyUnicode_CheckExact(name)), function
_PyObject_StoreInstanceAttribute, file dictobject.c, line 5426.
Fatal Python error: Aborted
Current thread 0x000100a98580 (most recent call first):
File "/Users/ronald/Projects/pyobjc-8/pyobjc-core/str.py", line 10 in
zsh: abort /tmp/py311/bin/python3 -Xdev str.py
--
components: Interpreter Core
messages: 414386
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: Crash when setting attribute with string subclass as the name
(--with-pydebug)
type: crash
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46903>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: I don't feel qualified to review the PR, but can confirm that this PR fixes this issue as well as the crash in PyObjC that I extracted my reproducer from. -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: @Pablo: this is a possible release blocker, hard crash for code that works in earlier releases. That said, I have a workaround on my end and IMHO a fix could wait for the next alpha. -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: > This is marked as a release blocker so I am holding the alpha release on > this. Is there anything we can do to unblock this issue? I marked the issue as a release blocker because it must not end up in a beta release, its probably not worth it to hold up an alpha release for this. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
Again without diving deep I've constructed a test case that is probably
relevant. I've pasted the diff below because I'm not yet convinced that it is
correct (in particular the value for "argv0". This would also require a second
test case that does something similar for a venv when using a framework build
(the test_venv_macos case seems to be for a regular install and not a framework
install)
With this tests case I get a test failure that matches my observations:
test test_getpath failed -- Traceback (most recent call last):
File "/Users/ronald/Projects/Forks/cpython/Lib/test/test_getpath.py", line
444, in test_framework_python
self.assertEqual(expected, actual)
^^
AssertionError: {'exe[273 chars]/9.8/bin/python9.8', 'base_prefix':
'/Library/[381 chars]ad']} != {'exe[273
chars]/9.8/Resources/Python.app/Contents/MacOS/Pytho[410 chars]ad']}
{'base_exec_prefix': '/Library/Frameworks/Python.framework/Versions/9.8',
- 'base_executable':
'/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8',
?^^^ ^
- ^
+ 'base_executable':
'/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python',
?
^ ^ ^
'base_prefix': '/Library/Frameworks/Python.framework/Versions/9.8',
'exec_prefix': '/Library/Frameworks/Python.framework/Versions/9.8',
'executable':
'/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8',
'module_search_paths':
['/Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip',
'/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8',
'/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload'],
'module_search_paths_set': 1,
'prefix': '/Library/Frameworks/Python.framework/Versions/9.8'}
test_getpath failed (1 failure)
The inline diff (and as mentioned before, I'm not sure if the value for "argv0"
is correct):
% git diff ../Lib/test/test_getpath.py
(main)cpython
diff --git a/Lib/test/test_getpath.py b/Lib/test/test_getpath.py
index 3fb1b28003..69b469f179 100644
--- a/Lib/test/test_getpath.py
+++ b/Lib/test/test_getpath.py
@@ -414,6 +414,36 @@ def test_custom_platlibdir_posix(self):
actual = getpath(ns, expected)
self.assertEqual(expected, actual)
+def test_framework_python(self):
+""" Test framework layout on macOS """
+ns = MockPosixNamespace(
+os_name="darwin",
+
argv0="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
+PREFIX="/Library/Frameworks/Python.framework/Versions/9.8",
+
ENV___PYVENV_LAUNCHER__="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
+
real_executable="/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python",
+)
+
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python")
+
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8")
+
ns.add_known_xfile("/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload")
+expected = dict(
+
executable="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
+prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+exec_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+
base_executable="/Library/Frameworks/Python.framework/Versions/9.8/bin/python9.8",
+base_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+
base_exec_prefix="/Library/Frameworks/Python.framework/Versions/9.8",
+module_search_paths_set=1,
+module_search_paths=[
+
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python98.zip",
+
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8",
+
"/Library/Frameworks/Python.framework/Versions/9.8/lib/python9.8/lib-dynload",
+],
+)
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: The debug build seems to indicate that slot memory is not initiated properly, a stack trace (note the argument to visit_validate at frame #7): * frame #0: 0x00019b60d9b8 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x00019b640eb0 libsystem_pthread.dylib`pthread_kill + 288 frame #2: 0x00019b57e314 libsystem_c.dylib`abort + 164 frame #3: 0x00010030c4f4 python.exe`fatal_error_exit(status=-1) at pylifecycle.c:2624:9 frame #4: 0x00010030c3cc python.exe`fatal_error(fd=2, header=1, prefix="_PyObject_AssertFailed", msg="_PyObject_AssertFailed", status=-1) at pylifecycle.c:2805:5 frame #5: 0x00010030be20 python.exe`_Py_FatalErrorFunc(func="_PyObject_AssertFailed", msg="_PyObject_AssertFailed") at pylifecycle.c:2821:5 frame #6: 0x000100169fe0 python.exe`_PyObject_AssertFailed(obj=0x000100d63690, expr=0x, msg="PyObject_GC_Track() object is not valid", file="../Modules/gcmodule.c", line=2187, function="visit_validate") at object.c:2293:5 frame #7: 0x000100351184 python.exe`visit_validate(op=0xcdcdcdcdcdcdcdcd, parent_raw=0x000100d63690) at gcmodule.c:2186:9 frame #8: 0x00010019845c python.exe`traverse_slots(type=0x000101813230, self=0x000100d63690, visit=(python.exe`visit_validate at gcmodule.c:2183), arg=0x000100d63690) at typeobject.c:1207:27 frame #9: 0x000100197fe8 python.exe`subtype_traverse(self=0x000100d63690, visit=(python.exe`visit_validate at gcmodule.c:2183), arg=0x000100d63690) at typeobject.c:1228:23 frame #10: 0x000100350fdc python.exe`PyObject_GC_Track(op_raw=0x000100d63690) at gcmodule.c:2212:11 -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: The crash itself happens during garbage collection: % python3.11 -Xdev t.py (master)pyobjc-8 Fatal Python error: Segmentation fault Current thread 0x000104ce0580 (most recent call first): Garbage-collecting And when using a debug build and -Xdev: ../Modules/gcmodule.c:2187: visit_validate: Assertion failed: PyObject_GC_Track() object is not valid Enable tracemalloc to get the memory block allocation traceback object address : 0x101a5f690 object refcount : 1 object type : 0x15503f230 object type name: MyModule object repr : Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed Python runtime state: initialized Current thread 0x0001019c0580 (most recent call first): File "/Users/ronald/Projects/Forks/cpython/build/t.py", line 12 in zsh: abort ./python.exe -Xdev t.py -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
Ronald Oussoren added the comment: This is with python 3.11 alpha 5 using the installer for macOS. -- ___ Python tracker <https://bugs.python.org/issue46891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46891] Crash in ModuleType subclass with __slots__
New submission from Ronald Oussoren :
The following crashes the interpreter in Python 3.11, and works fine in older
versions:
# --- script.py
import types
class MyModule (types.ModuleType):
__slots__ = (
"_MyModule__a",
"_MyModule__b",
)
def __init__(self, name):
super().__init__(name)
m = MyModule("name")
# -- end of file
The key in this is the ``__slots__`` definition: The script does not crash
without ``__slots__``, or with a slots tuple with 1 item.
This is a reproducer based on code in PyObjC.
--
components: Interpreter Core
keywords: 3.11regression
messages: 414294
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Crash in ModuleType subclass with __slots__
type: crash
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46891>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment: The change to _base_executable is the real problem. Venv creates the correct directory structure if I add a sitecustomize.py to the python path that sets _base_executable to the correct value. # sitecustomize import sys sys._base_executable = sys.executable # EOF Is sys._base_executable updated after running getpath.py? On first glance getpath.py does update config['base_executable'] and _PyConfig_FromDict reads that value back, but that's based on a quick scan through the code. I haven't tried debugging this yet. -- ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
The root cause likely is the calculation of sys._base_executable. In 3.10 this
is {sys.prefix}/bin/python3.10, while in 3.11 this is
{sys.prefix}/Resources/Python.app/Contents/MacOS/Python.
The venv library uses the incorrect value and therefore creates an incorrect
virtual environment.
--
components: +Interpreter Core
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] venv does not create "python" link in python 3.11
Ronald Oussoren added the comment:
This is be related to how the virtual environment is populated. In 3.10 the
"python3.10" name in the environment is a symlink to sys.executable. In 3.10
"Python" (not the capital) is a symlink to the binary in Python.app and
"python3.11" is a symlink to "Python". Given that the filesystem is case
preserving there is no "python" name.
The behaviour in 3.11 is clearly a bug: the virtual environment is no longer
using the launcher binary in "{sys.prefix]/bin" but directly uses the "real"
binary (in a framework build), and because of that scripts cannot use system
APIs that expect to run in an application bundle.
Listing "env/bin" in Python 3.10:
-rw-rw-r-- 1 ronald staff 9033 Mar 1 18:11 Activate.ps1
-rw-rw-r-- 1 ronald staff 2018 Mar 1 18:11 activate
-rw-rw-r-- 1 ronald staff 944 Mar 1 18:11 activate.csh
-rw-rw-r-- 1 ronald staff 2086 Mar 1 18:11 activate.fish
-rwxr-xr-x 1 ronald staff 269 Mar 1 18:11 pip
-rwxr-xr-x 1 ronald staff 269 Mar 1 18:11 pip3
-rwxr-xr-x 1 ronald staff 269 Mar 1 18:11 pip3.10
lrwxr-xr-x 1 ronald staff10 Mar 1 18:11 python -> python3.10
lrwxr-xr-x 1 ronald staff10 Mar 1 18:11 python3 -> python3.10
lrwxr-xr-x 1 ronald staff65 Mar 1 18:11 python3.10 ->
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10
In python3.11:
total 72
-rw-rw-r-- 1 ronald staff 9033 Mar 1 17:23 Activate.ps1
lrwxr-xr-x 1 ronald staff93 Mar 1 17:23 Python ->
/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app/Contents/MacOS/Python
-rw-rw-r-- 1 ronald staff 2018 Mar 1 17:23 activate
-rw-rw-r-- 1 ronald staff 944 Mar 1 17:23 activate.csh
-rw-rw-r-- 1 ronald staff 2086 Mar 1 17:23 activate.fish
-rwxr-xr-x 1 ronald staff 265 Mar 1 17:23 pip
-rwxr-xr-x 1 ronald staff 265 Mar 1 17:23 pip3
-rwxr-xr-x 1 ronald staff 265 Mar 1 17:23 pip3.11
lrwxr-xr-x 1 ronald staff 6 Mar 1 17:23 python3 -> Python
lrwxr-xr-x 1 ronald staff 6 Mar 1 17:23 python3.11 -> Python
--
components: +macOS
nosy: +ned.deily
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue46890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46890] vent does not create "python" link in python 3.11
New submission from Ronald Oussoren : In python3.10 and earlier "python3 -m venv something" creates "something/bin/python" as a symlink to the interpreter itself. In python3.11 (a5) the same command no longer creates "something/bin/python", but only the ".../python3" symlink. With this change the "python" command no longer refers to the interpreter in an activated virtualenv, but to a different binary on $PATH (if any). I tested using the Python 3.11a5 installer for macOS on python.org. -- components: Library (Lib) keywords: 3.11regression messages: 414278 nosy: ronaldoussoren priority: normal severity: normal status: open title: vent does not create "python" link in python 3.11 type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Ronald Oussoren added the comment: This is not a bug in CPython, at best this can be a feature request to make it possible to pickle lambda's (which IMHO is unlikely to happen). The "fork" and "spawn" start methods result in different behaviour in how data is copied into the new worker proces and there's nothing we can do about this. Note that the same difference in behaviour can be observed on Windows, which does not support the "fork" method at all. -- resolution: -> not a bug stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Ronald Oussoren added the comment: The default start method for multirprocessing was changed from "fork" to "spawn" on macOS. This was done because the "fork" method can easily be triggered into causing hard crashes (on macOS), in particular when the parent proces has called higher-level systemen APIs. The "spawn" method requires pickling the data and callable passed to the child proces, and that's not supported for lambda's. -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Something I forgot to mention: I don't think this is a bug in Tk now that I've looked into this more deeply. The integration problem between Tk and other users of the Cocoa event loop is unfortunate but not a bug. -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Categories make it possible to add methods to an existing class, but not new attributes. The latter shouldn't be a problem in principle for an NSApplication subclass because only a single instance of the application class will get created and you may as well use global variables for those. In some sense categories are syntactic sugar for monkey patching existing classes, commonly used to add convenience methods to Cocoa classes. -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Ronald Oussoren added the comment: There's a use case for using a dict for __slots__, pydoc will use a dict value for the slots as a mapping from attribute name to attribute documentation. Because of that it is not really worthwhile to transform the value of __slots__ during class definition. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Ronald Oussoren added the comment: W.r.t. augmented assignments, this is a good blog post about how they work under the hood: https://snarky.ca/unravelling-augmented-arithmetic-assignment/ -- ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: I've done some more research and this is an integration issue between pyglet and Tk. In particular: * Both pyglet and Tk use AppKit to implement their GUI * AppKit uses an NSApplication class, and in particular a singleton instance of that class, to represent the application, which will get instantiated during application startup * The Tk library uses a sublclass of NSApplication with additional functionality (TkApplication). * When pyglet is started first the NSApplication singleton is an instance of NSApplication and not of TkApplication, but Tk's implementation assumes that the singleton is an instance of TkApplicationo. A workaround for this issue is to make sure Tk is initialised before initialising pyglet. For example using this code at the start of the script: "from tkinter import Tk; root = Tk()" There's not much we can do about this in CPython, other than maybe filing an issue with the Tk project about this. I haven't looked at the Tk codebase and there cannot tell how hard it would be for then to avoid a dependency on TkApplication as a separate class (for example by implementing the additional functionality they need in a category on NSApplication). -- resolution: -> third party stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Oops, sorry: In Tk itself. -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: If I interpret the information I posted earlier correctly this is a bug in Tkinter, it calls a non-existing Objecive-C method (``-[NSApplication macOSVersion]``) and that results in an uncaught Objective-C exception and hence an abort(). BTW. All of this is using python 3.10.2 using the installer on python.org. -- components: +Tkinter ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: The last bit of the call stack according to lldb: * thread #2, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00018b3419b8 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x00018b374eb0 libsystem_pthread.dylib`pthread_kill + 288 frame #2: 0x00018b2b2314 libsystem_c.dylib`abort + 164 frame #3: 0x00018b331b50 libc++abi.dylib`abort_message + 132 frame #4: 0x00018b322f64 libc++abi.dylib`demangling_terminate_handler() + 332 frame #5: 0x00018b21a140 libobjc.A.dylib`_objc_terminate() + 144 frame #6: 0x00018b330ee4 libc++abi.dylib`std::__terminate(void (*)()) + 20 * frame #7: 0x00018b333c5c libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 36 frame #8: 0x00018b333c08 libc++abi.dylib`__cxa_throw + 140 frame #9: 0x00018b2118dc libobjc.A.dylib`objc_exception_throw + 352 frame #10: 0x00018b5531a0 CoreFoundation`-[NSObject(NSObject) doesNotRecognizeSelector:] + 144 frame #11: 0x00018b420360 CoreFoundation`___forwarding___ + 1728 frame #12: 0x00018b41fbe0 CoreFoundation`_CF_forwarding_prep_0 + 96 frame #13: 0x000102388a1c libtk8.6.dylib`GetRGBA + 64 frame #14: 0x0001023884a8 libtk8.6.dylib`SetCGColorComponents + 140 frame #15: 0x0001023888e0 libtk8.6.dylib`TkpGetColor + 544 frame #16: 0x0001022ea454 libtk8.6.dylib`Tk_GetColor + 220 frame #17: 0x0001022ddaa0 libtk8.6.dylib`Tk_Get3DBorder + 204 frame #18: 0x0001022dd8ac libtk8.6.dylib`Tk_Alloc3DBorderFromObj + 144 frame #19: 0x0001022eb810 libtk8.6.dylib`DoObjConfig + 832 frame #20: 0x0001022eb3cc libtk8.6.dylib`Tk_InitOptions + 348 frame #21: 0x0001022eb2c8 libtk8.6.dylib`Tk_InitOptions + 88 frame #22: 0x000102312cf0 libtk8.6.dylib`CreateFrame + 1448 frame #23: 0x000102312fe8 libtk8.6.dylib`TkListCreateFrame + 156 frame #24: 0x00010230bec0 libtk8.6.dylib`Initialize + 1848 frame #25: 0x00010026a2d4 _tkinter.cpython-310-darwin.so`Tcl_AppInit + 92 frame #26: 0x000100269f6c _tkinter.cpython-310-darwin.so`Tkapp_New + 548 frame #27: 0x000100269d44 _tkinter.cpython-310-darwin.so`_tkinter_create_impl + 268 frame #28: 0x00010026997c _tkinter.cpython-310-darwin.so`_tkinter_create + 240 frame #29: 0x000100bf71f0 Python`cfunction_vectorcall_FASTCALL + 88 -- ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Ronald Oussoren added the comment: Error output when running the script: 2022-02-01 22:15:32.213 Python[5468:5726153] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/d3/rc5nx4v12y96knh2px3bpqscgn/T/org.python.python.savedState 2022-02-01 22:15:32.362 Python[5468:5726153] -[NSApplication macOSVersion]: unrecognized selector sent to instance 0x105624bc0 2022-02-01 22:15:32.367 Python[5468:5726153] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSApplication macOSVersion]: unrecognized selector sent to instance 0x105624bc0' *** First throw call stack: ( 0 CoreFoundation 0x00018b4c01cc __exceptionPreprocess + 240 1 libobjc.A.dylib 0x00018b2117b8 objc_exception_throw + 60 2 CoreFoundation 0x00018b5531a0 -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x00018b420360 ___forwarding___ + 1728 4 CoreFoundation 0x00018b41fbe0 _CF_forwarding_prep_0 + 96 5 libtk8.6.dylib 0x000100940a1c GetRGBA + 64 6 libtk8.6.dylib 0x0001009404a8 SetCGColorComponents + 140 7 libtk8.6.dylib 0x0001009408e0 TkpGetColor + 544 8 libtk8.6.dylib 0x0001008a2454 Tk_GetColor + 220 9 libtk8.6.dylib 0x000100895aa0 Tk_Get3DBorder + 204 10 libtk8.6.dylib 0x0001008958ac Tk_Alloc3DBorderFromObj + 144 11 libtk8.6.dylib 0x0001008a3810 DoObjConfig + 832 12 libtk8.6.dylib 0x0001008a33cc Tk_InitOptions + 348 13 libtk8.6.dylib 0x0001008a32c8 Tk_InitOptions + 88 14 libtk8.6.dylib 0x0001008cacf0 CreateFrame + 1448 15 libtk8.6.dylib 0x0001008cafe8 TkListCreateFrame + 156 16 libtk8.6.dylib 0x0001008c3ec0 Initialize + 1848 17 _tkinter.cpython-310-darwin.so 0x0001008762d4 Tcl_AppInit + 92 18 _tkinter.cpython-310-darwin.so 0x000100875f6c Tkapp_New + 548 19 _tkinter.cpython-310-darwin.so 0x000100875d44 _tkinter_create_impl + 268 20 _tkinter.cpython-310-darwin.so 0x00010087597c _tkinter_create + 240 21 Python 0x00010109b1f0 cfunction_vectorcall_FASTCALL + 88 22 Python 0x000101169f48 call_function + 132 23 Python 0x000101161fac _PyEval_EvalFrameDefault + 23072 24 Python 0x00010115ad5c _PyEval_Vector + 360 25 Python 0x000101033dac _PyObject_FastCallDictTstate + 96 26 Python 0x0001010c7cbc slot_tp_init + 196 27 Python 0x0001010be950 type_call + 312 28 Python 0x000101033af4 _PyObject_MakeTpCall + 136 29 Python 0x00010116a040 call_function + 380 30 Python 0x000101160a18 _PyEval_EvalFrameDefault + 17548 31 Python 0x00010115ad5c _PyEval_Vector + 360 32 Python 0x000101169f48 call_function + 132 33 Python 0x000101160a18 _PyEval_EvalFrameDefault + 17548 34 Python 0x00010115ad5c _PyEval_Vector + 360 35 Python 0x000101169f48 call_function + 132 36 Python 0x000101161404 _PyEval_EvalFrameDefault + 20088 37 Python 0x00010115ad5c _PyEval_Vector + 360 38 Python 0x00010115cb3c _PyEval_EvalFrameDefault + 1456 39 Python 0x00010115ad5c _PyEval_Vector + 360 40 Python 0x000101169f48 call_function + 132 41 Python 0x000101160a18 _PyEval_EvalFrameDefault + 17548 42 Python 0x00010115ad5c _PyEval_Vector + 360 43 Python 0x00010115cb3c _PyEval_EvalFrameDefault + 1456 44 Python 0x00010115ad5c _PyEval_Vector + 360 45 Python 0x00010115cb3c _PyEval_EvalFrameDefault + 1456 46 Python 0x00010115ad5c
[issue46550] __slots__ updates despite being read-only
Ronald Oussoren added the comment: Python's is behaving as expected here (but see below): the slots definition tells the interpreter which attribute names can be set on an instance and "__slots__" is not one of those attributes in your code. "a.__slots__ += ..." will try to set the "a.__slots__" attribute (see Eryk's message for documentation on this) and that results in the exception you are seeing. What surprised me is that A.__slots__ is mutable at all, the value of that attribute during class construction affects the layout of instances and that layout won't change when you change A.__slots__ later on. That is: class A: __slots__ = ['a'] a = A() a.a = ... # OK a.b = ... # raises AttributeError A.__slots__ = ['b'] a.a = ... # still OK a.b = ... # still raises AttributeError I don't know if this should be considered a bug or that this is intended behaviour. -- components: +Interpreter Core -Library (Lib) nosy: +ronaldoussoren versions: +Python 3.11, Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
Change by Ronald Oussoren : -- components: +macOS nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46514] Pathlib Path.touch() seems to ignore groups write bit for mode parameter
Ronald Oussoren added the comment: The touch method combines the mode you specify with the active umask (set by os.umask()). This is fairly standard behaviour for Unix APIs that accept a file mode. This is documented at: https://docs.python.org/3/library/pathlib.html#pathlib.Path.touch -- nosy: +ronaldoussoren resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46514> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46412] PyQT6 projects crashes with python 3.10
Ronald Oussoren added the comment: This is most likely a problem with PyQt6. Please ask that project first (with a clearer description of what goes wrong and on which platforms). -- nosy: +ronaldoussoren resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34602] python3 resource.setrlimit strange behaviour under macOS
Ronald Oussoren added the comment: > My understanding of the resolution of this ticket is that it is still not > possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit. > Is that correct? Yes, the code in msg324731 still fails. We're still using the mechanism described in msg324818, but with a larger stack size for some builds. It is rather annoying that -Wl,-stack_size, sets a hard limit on the stack size, rather than overriding the soft limit. I guess we could change the startup code for the interpreter executable (Py_Main or related code) to set the RLIMIT_STACK to a larger value when it is too small, that way applications can still pick a different (and in particular larger) value. @ned.deily, @lukasz.langa: reopen this issue or open a new one? -- versions: +Python 3.10, Python 3.11 -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46248] Compilation errors on macOS
Ronald Oussoren added the comment: The libraries you mention are 3th party projects. Please check with the project first. I've look at the GitHub repository for libmobiledevice and have no idea how they determine the compiler flags for Python. As mentioned in an earlier version "python-config" is the documented way to fetch such flags. -- ___ Python tracker <https://bugs.python.org/issue46248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46248] Compilation errors on macOS
Ronald Oussoren added the comment: Part of the problem here is that most keys in the result of sysconfig.get_config_vars() are copied as-is from the CPython Makefile and pyconfig.h header file. The keys copied from the Makefile are in a lot of cases not useful for users of python because they contain values that are only useful while building CPython itself. Without knowing your use case it is hard to point you to a better solution, but as Ned writes in general just follow the instructions from the extending and embedding documentation. -- ___ Python tracker <https://bugs.python.org/issue46248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46174] Feature Request for Python Interfaces
Ronald Oussoren added the comment: I agree with Terry. This requires a clear proposal that describes the behaviour and differences with ABC-s. I'm closing this issue for now. -- nosy: +ronaldoussoren resolution: -> later stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46117] tk could not refresh auto in mac os
Ronald Oussoren added the comment: I don't know why it doesn't work for you. The version of Tk looks recent enough. As I mentioned before I don't see this problem using the script in your initial message, it works fine both with and without changing the size of the window. You could try installing Python 3.10.1, which should get you the exact some binary and Tcl/Tk version as I'm using. That might fix the problem. Btw. I'm on an M1 MacBook, although that shouldn't be relevant here. -- ___ Python tracker <https://bugs.python.org/issue46117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46117] tk could not refresh auto in mac os
Ronald Oussoren added the comment:
The script seems to work fine for me, python 3.10.1 on macOS 12.1. I used the
python.org installer.
Did you install Python from source or using the installer? What's the output of
``python3 -m test.pythoninfo``, in particular the lines related to Tcl/Tk at
the end?
For example:
...
time.tzname: ('CET', 'CEST')
tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.12
zlib.ZLIB_RUNTIME_VERSION: 1.2.11
...
--
___
Python tracker
<https://bugs.python.org/issue46117>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40477] Python Launcher app on macOS 10.15+ fails to run scripts
Ronald Oussoren added the comment: Pfff Apple's documentation is too incomplete. In recent versions the apple events entitlement only works when the program also has an NSAppleEventsUsageDescription key in Info.plist with a string value that describes why it needs the entitlement, this information is shown to the user on first launch. When I add this key to info.plist and resign the launcher works. I forgot to create a screenshot of this and cannot recreate the system dialog that gets shown, probably documentement somewhere that I haven't found yet... For now I used: NSAppleEventsUsageDescription Python Launcher needs this to run scripts in a Terminal window This requires no code changes. -- ___ Python tracker <https://bugs.python.org/issue40477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40477] Python Launcher app on macOS 10.15+ fails to run scripts
Ronald Oussoren added the comment:
It looks like this is related to code signing and entitlements, in particular:
* On my system Terminal.app is in the "Automation" list in the Security &
Privacy control panel, and none of the installed Python Launchers are
* The script let below works (assuming PyObjC is installed):
```
import ScriptingBridge
command = """cd '' &&
'/Library/Frameworks/Python.framework/Versions/3.10/bin/python3'
'/Users/ronald/issuequery.py' && echo Exit status: $? && exit 1"""
app =
ScriptingBridge.SBApplication.applicationWithBundleIdentifier_("com.apple.Terminal")
app.activate()
res = app.doScript_in_(command, None)
print(res)
```
* Python Launcher does not work when launched normally
* Python Launcher *does* work when I run "/Applcations/Python 3.X/Python
Launcher/Contents/MacOS/Python Launcher" in Terminal.app and try to open a
python file using Python Launcher
- I've tried this with 3 variants of Python Launcher: 3.9.7 from python.org
installer, no modifications; 3.10.1 from python.org installer, stripped
signature and resigned ad-hoc; 3.11 installed from source with ScriptingBridge.
As mentioned before I've experimented with ScriptingBridge in Python Launcher,
replacing "doscript.m" by the code below:
```
#import
#import
#import "doscript.h"
extern int
doscript(const char *command)
{
NSObject* terminalApp = [SBApplication
applicationWithBundleIdentifier:@"com.apple.Terminal"];
//[terminalApp activate];
NSObject* res = [terminalApp doScript:[NSString
stringWithUTF8String:command] in:nil];
NSRunAlertPanel(@"script result", @"%@", @"ok",nil, nil, res);
return 0;
}
```
That's equivalent to the python code I posted earlier. This is not production
quality code, it compiles with a warning about "doScript:in:" that can be
avoided by a different way of using ScriptingBridge. That's irrelevant for this
experiment though.
When I test the call to "doScript:in:" *fails* (returns nil) when launching the
app regularly, and *succeeds* when running as a terminal command (as mentioned
earlier).
--
___
Python tracker
<https://bugs.python.org/issue40477>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40477] Python Launcher app on macOS 10.15+ fails to run scripts
Ronald Oussoren added the comment: FWIW, I'm experimenting with using Scripting Bridge instead of raw Apple Events in Python Laucher. Mostly to check if that fixes the issue because I can run scripts in Terminal using Scripting Bridge from a Python script using PyObjC. Scripting Bridge would also result in slightly easier to read code. On my machine (M1 Mac Book running macOS 12.0.1) Python Launcher cannot start scripts (as described in this issue). Same when I strip code signatures (and ad-hoc sign without using the hardened runtime) -- ___ Python tracker <https://bugs.python.org/issue40477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46043] Python Launcher Not Opening Files.
Ronald Oussoren added the comment: Are you on macOS 10.15 or later? If so, this is a duplicate of issue40477. A workaround mentioned in that issue is to make sure that Terminal.app is open. -- type: crash -> behavior ___ Python tracker <https://bugs.python.org/issue46043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45998] Document best practice for including and linking python framework
New submission from Ronald Oussoren : There are two ways to develop against a Python.framework on MacOS: 1. Use the regular Unix pattern with "#include "Python.h", using compiler flags to select the right headers and libraries. 2. Using the native framework pattern with "#import " and "-framework Python" Both works, but the latter has the disadvantage of loosing control over which version of Python is used when multiple versions are installed. The version is selected by the "Current" link in the framework, which is overwritten to point to whatever version was last installed or updated. IMHO we should document this pitfall in the C API documentation. -- assignee: docs@python components: Documentation, macOS messages: 407821 nosy: docs@python, ned.deily, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Document best practice for including and linking python framework type: enhancement versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue45998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45983] PyType_Spec.name must remain valid after PyType_FromSpec
Ronald Oussoren added the comment: I just noticed this duplicates #45315, sorry about the noise. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> `PyType_FromSpec` does not copy the name ___ Python tracker <https://bugs.python.org/issue45983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45983] PyType_Spec.name must remain valid after PyType_FromSpec
New submission from Ronald Oussoren : The documentation for PyType_Spec and the related functions is not clear about the required lifetime of fields of PyType_Spec. In particular, PyType_Spec.name must remain valid for the entire lifetime of types created with PyType_FromSpec*. The documentation doesn't mention this. I ran into this with code that calculates the name as needed an cleans up the memory used for the type spec after creating the type. The type appears to work fine when looking at it in Python scripts, but the tp_name slot is wrong. -- assignee: docs@python components: Documentation messages: 407676 nosy: docs@python, ronaldoussoren priority: normal severity: normal status: open title: PyType_Spec.name must remain valid after PyType_FromSpec type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45933] Illegal Instrution (Core Dumped)
Ronald Oussoren added the comment: Is arch corei7-avx compatible with your CPU? One way to test is to leave out -mtune=... and -march=... when building python. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24725] test_socket testFDPassEmpty fails on OS X 10.11+ with "Cannot allocate memory"
Ronald Oussoren added the comment: The reproducer script and .c file I added earlier do not fail with "Cannot allocate memory" on macOS 12.0.1. I haven't checked yet if this is enough to avoid test failures in the (now skipped) testFDPassEmpty. -- ___ Python tracker <https://bugs.python.org/issue24725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45939] PyErr_SetObject documentation lacks mention of reference counting
Ronald Oussoren added the comment: The default behaviour of functions is to not steal references, in general only exceptions to this are documented. Likewise with return values: by default the result is a strong reference, and borrowed references are documented as such. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45889] pathlib: Path.match does not work on paths
Ronald Oussoren added the comment:
I don't think our opinions about this will converge, I'm therefore leaving this
discussion.
>> would ``Path("dir/some.py").match(Path("*.py"))`` return?
>
> str(Path("*.py")) == "*.py"
>
> So no problems here.
I do think this is a problem, treating a Path like an pattern feels wrong to me.
--
___
Python tracker
<https://bugs.python.org/issue45889>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45889] pathlib: Path.match does not work on paths
Ronald Oussoren added the comment:
I'm not sure what your code tries to accomplish, does it check that
``f.parent`` refers to the same location as ``ref_file``? A clearer solution
for that would be ``f.parent.resolve() == ref_file.resolve()``.
The argument to match, glob and rglob cannot be Paths because the argument is
not a path but a pattern. Those are conceptually different.
What would ``Path("dir/some.py").match(Path("*.py"))`` return?
--
___
Python tracker
<https://bugs.python.org/issue45889>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45889] pathlib: Path.match does not work on paths
Ronald Oussoren added the comment: Match doesn't match paths, but basically does a regular expression match on the textual representation (using glob syntax instead of normal regular expression syntax). Because of this I don't agree with your idea that anything that can match a path is a sub-path. What is your use case for this? -- ___ Python tracker <https://bugs.python.org/issue45889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45889] pathlib: Path.match does not work on paths
Ronald Oussoren added the comment: This would definitely be a new feature and not something that can be back ported. That said, I don't understand why it is desirable to use a Path as the match argument. That argument is a glob pattern (such as "*.py") and not a file name . -- nosy: +ronaldoussoren versions: +Python 3.11 -Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45839] python3 executable is able to install pandas
Ronald Oussoren added the comment: Could you check with "curl -k https://pypi.org/ >/dev/null" what certificate is used by PyPI? On my system I get (amongst other output): ... * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=pypi.org * start date: Oct 22 18:55:44 2021 GMT * expire date: Nov 23 18:55:43 2022 GMT * subjectAltName: host "pypi.org" matched cert's "pypi.org" * issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R3 DV TLS CA H2 2021 * SSL certificate verify ok. ... Note how the issuer is GlobalSign. If you see some other certificate authority, or get an error from curl due to the same certificate verification problem, you have something on the path between you and PyPI that intercepts the connection, such as a corporate proxy. Pip appears to have a way to override certificate verification, you'll have to (a) read pip's manual for that and (b) be *very* sure you know what's going on before you start trusting some other CA that's not in the global trust root used by pip and certify. -- ___ Python tracker <https://bugs.python.org/issue45839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45758] Crash on Py_DecRef'ing builtin object from previous run
Ronald Oussoren added the comment: IMHO your code is buggy, as Hai Shi also indicates. After Py_Finalize all objects in all (sub-)interpreters are deallocated unless there are bugs in the interpreter. Because of this "..., item should still be alive" in your sample code is incorrect: the reference should be considered to be invalid and cannot be used again. -- nosy: +ronaldoussoren resolution: -> not a bug stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue45758> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45793] execute shell command ./configure with python subprocess.popen, os.system ... checking build system type... is wrong
Ronald Oussoren added the comment: The problem will go away when you install and use an arm64 or universal2 variant of Python. This is behaviour of macOS and cannot be changed in CPython. -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45793] execute shell command ./configure with python subprocess.popen, os.system ... checking build system type... is wrong
Ronald Oussoren added the comment: I'm assuming you run on a M1* system. What's the architecture for the python binary (run "file $(which python3)" in a shell to get this information, excluding the quotes)? If the binary supports only x86_64 you might run into a "feature" of macOS: subprocesses started from a Rosetta 2 process also prefer to run in emulation. This can also be demonstrated using the system install of perl, for example: % perl -e 'print `arch`' arm64 % arch -x86_64 perl -e 'print `arch`' i386 There sadly doesn't appear to be documentation about this on Apple's site. Note that the universal2 variants of the installers on python.org natively support both x86_64 and arm64. -- ___ Python tracker <https://bugs.python.org/issue45793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45779] multiprocessing initializer error with CPython 3.9.6 on Apple Silicon
Ronald Oussoren added the comment: Please include reproducer code in the issue itself, not on some external side. That said, the error you're getting is related to the start method used by multiprocessing. On Linux the start method is fork, on macOS (and Windows) the start method is spawn. The latter requires that data that's passed to the subprocess can be pickled. We use the "spawn" method on macOS because forking without calling execv is unsafe on macOS when higher level system APIs are used. -- nosy: +ronaldoussoren resolution: -> not a bug stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue45779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45747] Detect dbm and gdbm dependencies in configure.ac
Ronald Oussoren added the comment: dbm_open is in libc on macOS. likely due to being in SUSv2. The implementation in libc appears to be suboptimal (for example: issue33074), although I wouldn't teach configure.ac to ignore the system version of the library. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45743] Cleanup and simplify setup.py
Ronald Oussoren added the comment: 1) __APPLE_USE_RFC_3542 should have been in socketmodule.c from the start, not sure why it was added in setup.py. 2) as you and Ned noticed -search_paths_first has been the default for a long while, we can just drop it and anyone building on ancient systems can add the flag to CFLAGs/LDFLAGS as needed. IIRC we added the flag to be able to build with local copies of libraries also shipped in the OS, in particular when using static libraries for those local copies. 3) I don't know about detect_dbm_gdbm, and don't use those libraries myself. It would be nice to be able to open system files created using dbopen etc, but on the other hand there is at least one bug report complaining about data corruption when using one o the dbm extensions linked with the system version of the library. 4/5) Fine by me, although I'm slightly worried about using pkg-config because the system doesn't ship that tool. Something you don't mention is the logic dealing with SDK roots. I haven't checked yet if similar logic would be necessary in configure. With some luck it isn't, but that depends on what's supported by autoconf and the particular probes we want to use. @Ned: Not being able to use system versions of libraries is a bit annoying, but that's something you already have to do due to openssl. Maybe we should also try to clean up and refactor the build-installer.py script to do have a way to build/install those 3th-party dependencies. -- ___ Python tracker <https://bugs.python.org/issue45743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Ronald Oussoren added the comment: > Where do you think that "feature" is documented? I'd have to check, but I didn't learn this from Twitter, although it wouldn't surprise me if I learned this from a WWDC talk. The beta for Big Sur never identified itself as 10.16 other than through this feature. I guess Apple determined that too many applications only looked at the minor version determine if the current system is new enough. Applications compiled with/linked against a 11.0 or 12.0 SDK will always just see the real system version. Note that this also affects programs just opening the SystemVersion.plist file, that will get substituted by an alternative version when the opening process links against an older SDK. Calling sw_vers and parsing the output does return the right version though. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Ronald Oussoren added the comment: > Heads up! A strange Apple quirk has been identified which could affect the > file dialog behavior if the Tk library is compiled on macOS 10.XX and used on > macOS 11 or 12. (I am not sure if this applies here.) I'm pretty sure that's a documented feature. Any code compiled with a 10.15 or earlier SDK will never see version 11.0 or later when using regular in process APIs (and IIRC that includes usage of @available/__builtin_available) -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45641] Error In opening a file through Idle
Ronald Oussoren added the comment: Are you using macOS 12 (Monterey)? I get an error as well using that version of the OS (see open-error). The error happens within a second or two after opening the open dialog, without interacting with the dialog in any way. This is on an M1 laptop running macOS 12.0.1. This is likely the same issue as described in #44828. In particular, I get the same error message when I run the reproducer script in that issue. I'm adding the Tkinter component as well because this is likely a problem -- components: +Tkinter Added file: https://bugs.python.org/file50405/open-error.png ___ Python tracker <https://bugs.python.org/issue45641> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45447] IDLE: Support syntax highlighting for .pyi stub files
Ronald Oussoren added the comment: The most straightforward change for macOS is to add “pyi” to the list of extensions in “Mac/IDLE/IDLE.app/Contents/Info.plist”. That way IDLE will be seen as a valid editor for .pyi files. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Ronald Oussoren added the comment: Marc, thanks for the update. Will there be a Tcl/Tk release soonish that includes this fix? Alternatively, is there patch that we can apply to the latest release when building the copy of Tk included with the installers? -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44841] filemode in repr of ZipInfo, but is not a ZipInfo attribute
Ronald Oussoren added the comment: The repr() output of a ZipInfo contains filemode, but it is not an attribute of those objects, see <https://docs.python.org/3/library/zipfile.html#zipinfo-objects> for a list of attributes and methods. Adding an @property for mode that extracts the mode (as an integer) from the external_attr could be useful, that avoids having to know about that encoding in users of the library. You currently have to extract the mode yourself. Luckily that isn't too hard, basically: ```mode = info.external_attr >> 16```. Only use this when the value is not 0, as it will be zero when the archive was created by software that doesn't store a mode. You can convert this integer to a human readable string using the function stat.filemode(). I've changed the version to 3.11 because adding a mode attribute to ZipInfo would be a new feature and is therefore only possible in a new feature release. -- title: ZipInfo crashes on filemode -> filemode in repr of ZipInfo, but is not a ZipInfo attribute versions: +Python 3.11 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue44841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45267] New install Python 3.9.7 install of Sphinx Document Generator fails
Ronald Oussoren added the comment: The error in the attached file says that one of the dependencies could not be found, in particular the "packaging" library. This doesn't look like a bug in CPython or pip, but more a general support question. I kindly ask you to visit one of the python forums or mail lists (for example https://discuss.python.org). -- nosy: +ronaldoussoren resolution: -> not a bug stage: -> resolved status: open -> pending type: -> behavior ___ Python tracker <https://bugs.python.org/issue45267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45251] signal.SIGCLD alias is not available on OSX
Ronald Oussoren added the comment: The documentation for the SIG* constants also mentions: SIG* All the signal numbers are defined symbolically. For example, the hangup signal is defined as signal.SIGHUP; the variable names are identical to the names used in C programs, as found in . The Unix man page for ‘signal()’ lists the existing signals (on some systems this is signal(2), on others the list is in signal(7)). Note that not all systems define the same set of signal names; only those names defined by the system are defined by this module. This is however mentioned halfway through the list of constants. I'm not sure why this is so, IMHO it would be clearer to move the fragment I quote to the start of the module constants section. We shouldn't define SIGCLD on platforms that don't have this name available in their libc headers, which includes macOS. If the fragment above were moved to the start of the section no further updates would be required (IMHO). -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44841] ZipInfo crashes on filemode
Ronald Oussoren added the comment: I'm not sure what the issue is here. ZipInfo does not have a filemode attribute, that's why it is not in ZipInfo.__slots__. That said, it might be interesting to add a property to ZipInfo that extracts the file mode from ZipInfo.external_attr. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue44841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45241] python REPL leaks local variables when an exception is thrown
Ronald Oussoren added the comment: I'd expect that there'd be at least one instance of X alive due to sys.last_value and in particular sys.last_traceback (which has a reference to the stack frame which contains references to local variables). Btw. I cannot reproduce this with Python 3.9.7 installed with the Python.org installer (on MacOS 11): Python 3.9.7 (v3.9.7:1016ef3790, Aug 30 2021, 16:25:35) [Clang 12.0.5 (clang-1205.0.22.11)] on darwin When I introduce a reference loop the number of X() instances does grow, but only until the cyclic garbage collector runs (for example when gc.collect is called). I used slightly tweaked code to investigate: class Y: pass class X: def __init__(self): self.y = Y() self.y.x = self pass def dump(): import gc #gc.collect() objs = gc.get_objects() for obj in objs: if isinstance(obj, X): print(obj) def f(): x = X() raise Exception() f() -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45183] Unexpected exception with zip importer
Ronald Oussoren added the comment:
I just noticed that I'm unnecessarily obtuse in my description of a possible
fix, the diff (without test update):
% git diff Lib/zipimport.py
(main)cpython
diff --git a/Lib/zipimport.py b/Lib/zipimport.py
index c55fec6aa1..43ac6cbe57 100644
--- a/Lib/zipimport.py
+++ b/Lib/zipimport.py
@@ -334,7 +334,7 @@ def invalidate_caches(self):
_zip_directory_cache[self.archive] = self._files
except ZipImportError:
_zip_directory_cache.pop(self.archive, None)
-self._files = None
+self._files = {}
def __repr__(self):
With that change the exception should not happen, and the now stale zipimporter
would be ignored when flushing the cache while the zipfile referenced by the
zip importer instance has been removed.
That said, I haven't tested this and won't create a PR because my local tree is
(still) a mess.
--
___
Python tracker
<https://bugs.python.org/issue45183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45183] Unexpected exception with zip importer
Change by Ronald Oussoren : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue45183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45183] Unexpected exception with zip importer
Change by Ronald Oussoren : -- nosy: +pablogsal, twouters ___ Python tracker <https://bugs.python.org/issue45183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45183] Unexpected exception with zip importer
New submission from Ronald Oussoren : The attached file demonstrates the problem: If importlib.invalidate_caches() is called while the zipfile used by the zip importer is not available the import system breaks entirely. I found this in a testsuite that accedently did this (it should have updated sys.path). I get the following exception: $ python3.10 t.py Traceback (most recent call last): File "/Users/ronald/Projects/modulegraph2/t.py", line 27, in import uu File "", line 1027, in _find_and_load File "", line 1002, in _find_and_load_unlocked File "", line 945, in _find_spec File "", line 1430, in find_spec File "", line 1402, in _get_spec File "", line 168, in find_spec File "", line 375, in _get_module_info TypeError: argument of type 'NoneType' is not iterable This exception is not very friendly This particular exception is caused by setting self._files to None in the importer's invalidate_caches method, while not checking for None in _get_modules_info. I'm not sure what the best fix would be, setting self._files to an empty list would likely be the easiest fix. Note that the script runs without errors in Python 3.9. -- files: repro.py keywords: 3.10regression messages: 401698 nosy: ronaldoussoren priority: normal severity: normal status: open title: Unexpected exception with zip importer versions: Python 3.10, Python 3.11 Added file: https://bugs.python.org/file50279/repro.py ___ Python tracker <https://bugs.python.org/issue45183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45105] Incorrect handling of unicode character \U00010900
Ronald Oussoren added the comment: @Steven: the difference between indexing and the repr of list() is also explained by Eryk's explanation. s = ... # (value from msg401078) for x in repr(list(s)): print(x) The output shows characters in the expected order. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45161] _Py_DecodeUTF8_surrogateescape not exported from 3.10 framework build
Ronald Oussoren added the comment: I've switched py2app to Py_DecodeLocale, which is a public API introduced in 3.5 to accomplish the same task. I'm leaving the issue open in case hiding the symbol is unintentional. -- ___ Python tracker <https://bugs.python.org/issue45161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45161] _Py_DecodeUTF8_surrogateescape not exported from 3.10 framework build
New submission from Ronald Oussoren : The symbol _Py_DecodeUTF8_surrogateescape is not exported from Python.framework on macOS in Python 3.10. The symbol was exported in earlier versions of 3.x. I'm not sure if this was intentional, so far I haven't been able to find when this was changed. This change breaks py2app which uses _Py_DecodeUTF8_surrogateescape to convert the C argv array to an array of 'wchar_t*' for use with Python's C API. -- components: C API, macOS messages: 401564 nosy: ned.deily, ronaldoussoren priority: normal severity: normal status: open title: _Py_DecodeUTF8_surrogateescape not exported from 3.10 framework build versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45067] Failed to build _curses on CentOS 7
Ronald Oussoren added the comment: According to https://invisible-island.net/ncurses/NEWS.html#index-t20170401 the function extended_color_content was introduced in 2017, maybe the detection of support for this function doesn't work properly for some reason (although the preprocessor logic in Modules/_cursesmodule.c looks sane). That said, I don't have a CentOS VM at the moment so cannot debug this myself. -- ___ Python tracker <https://bugs.python.org/issue45067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45100] Teach help about typing.overload()
Ronald Oussoren added the comment: I agree that this would be nice to have, but wonder how help() could access that information. The two @overload definitions will be overwritten by the non-overload one at runtime, and hence will ever been seen by help(). -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45067] Failed to build _curses on CentOS 7
Ronald Oussoren added the comment: You stripped too much output from the build, in particular you removed the part where _curses failed to build. The output you show only says that _cursus_panel failed verification because _cursus could not be imported. Could you add the build failure for the _cursus module as well? Rerunning make should give a more manageable output. -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45020] Freeze all modules imported during startup.
Change by Ronald Oussoren : -- nosy: +ronaldoussoren ___ Python tracker <https://bugs.python.org/issue45020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
