This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients bettyrab, ned.deily, ronaldoussoren
Date 2021-09-26.22:26:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1632695206.48.0.802918727916.issue44933@roundup.psfhosted.org>
In-reply-to
Content
> the "reliable way to run under rosetta" is using "arch -x86_64 python3". I don't particularly like having another executable to accomplish the same goal.

Unfortunately, using "arch" is *not* a reliable way in general. It works fine for the initial invocation of the interpreter but things fall apart when a Python program tries to invoke another Python interpreter in a subprocess. The standard idiom for finding the location of the running interpreter is to use the contents of sys.executable. But that merely contains the name of the interpreter file, thus the additional "arch" arguments are lost and the interpreter will launch in the subprocess using the default arch, which may result in a failure (if you are lucky) or, worse, will silently run under the wrong architecture potentially giving misleading results. The most notable example of this is while running the python test suite. We ran into this same issue years ago with the "intel" universal-arch build option which is why we added a "python3-32" executable to provide a reliable way to force 32-bit execution on a 64-bit-capable Mac. The need for "python3-intel64" will eventually go away once Rosetta2 is no longer supported.
History
Date User Action Args
2021-09-26 22:26:46ned.deilysetrecipients: + ned.deily, ronaldoussoren, bettyrab
2021-09-26 22:26:46ned.deilysetmessageid: <1632695206.48.0.802918727916.issue44933@roundup.psfhosted.org>
2021-09-26 22:26:46ned.deilylinkissue44933 messages
2021-09-26 22:26:46ned.deilycreate