Documentation build overview

📚 cpython-previews | 🛠️ Build #33776618 | 📁 Comparing e59ddbc against main (46d1809)

  🔍 Preview build  

+ Added

• library/asyncio-tools.html
• library/tkinter.fontchooser.html
• library/tkinter.systray.html

± Modified

• glossary.html
• license.html
• py-modindex.html
• c-api/bytes.html
• c-api/dict.html
• c-api/exceptions.html
• c-api/float.html
• c-api/frame.html
• c-api/gen.html
• c-api/intro.html
• and 131 more...

The SC agreed to add the arch-specific abi3t .so filename. .abi3t.so should always be there.
we should do the same for abi3 as for abi3t. (I talked with the RM and a SC member & they agree; if anyone wants an official clarification from the SC, ask them.)

I'll update & merge this PR.

This was previously a commit following on from #122917. There has been some movement in there since this was filed. Cherry-picked those commits for here.

This change adds the following strings to importlib.machinery.EXTENSION_SUFFIXES on a regular build:

• Emscripten: .abi3-wasm32-emscripten.so and .abi3t-wasm32-emscripten.so
• macOS: .abi3-darwin.so and .abi3t-darwin.so
• Ubuntu (x86-64): .abi3-x86_64-linux-gnu.so and .abi3t-x86_64-linux-gnu.so
• WASI: .abi3-wasm32-wasi.so and .abi3t-wasm32-wasi.so

On Free Threading, it adds the following string to importlib.machinery.EXTENSION_SUFFIXES:

• macOS: .abi3t-darwin.so
• Ubuntu (x86-64): .abi3t-x86_64-linux-gnu.so

For example, no new string is added on these platforms:

• FreeBSD
• Windows

On the PR gh-122917, @stefanor wrote that the change only impacts Linux. But it does impact other platforms: Emscripten, macOS and WASI for example.

Is it expected/useful to use these new suffixes on Emscripten/WASI? For example, use .abi3-wasm32-emscripten.so suffix instead of .abi3.so.

On macOS, we support Intel and AArch64 architectures but SOABI_PLATFORM is just darwin (without the architecture). Is it expected to omit the architecture from the extension suffix (just darwin in .abi3-darwin.so and .abi3t-darwin.so)? Does it mean that a FAT binary should be produced with multiple architectures?

The cryptography uses the stable ABI. On PyPI, I can only see download files for ARM64 on macOS: https://pypi.org/project/cryptography/#files.

This change adds the following strings to importlib.machinery.EXTENSION_SUFFIXES on a regular build:

• Emscripten: .abi3-wasm32-emscripten.so and .abi3t-wasm32-emscripten.so
• macOS: .abi3-darwin.so and .abi3t-darwin.so
• Ubuntu (x86-64): .abi3-x86_64-linux-gnu.so and .abi3t-x86_64-linux-gnu.so
• WASI: .abi3-wasm32-wasi.so and .abi3t-wasm32-wasi.so

no new string is added on these platforms:

• FreeBSD
• Windows

So, I primarily care about Linux here, that's where the pain is. And that's probably the platform where working with multiple architectures is the most common.

To me the addition makes sense and is potentially useful on all of those platforms (FreeBSD and Windows too). But figuring out the details for this all would probably take some time. We could restrict it to Linux only to get this merged now.

Fat binaries are common on macOS, but you'd only build one at a time, and combine them into a fat binary.

This change adds the following strings to importlib.machinery.EXTENSION_SUFFIXES on a regular build:

Maybe we're overthinking this. These platforms already have the additional .so extension suffix, we're just doing the same for abi3 and abi3t.

To me the addition makes sense and is potentially useful on all of those platforms (FreeBSD and Windows too).

Currently, we don't support the "platform triplet" on FreeBSD (same on OpenBSD or NetBSD).

The PLATFORM_TRIPLET variable in configure.ac is set by:

AC_MSG_CHECKING([for the platform triplet based on compiler characteristics])
if $CPP $CPPFLAGS $srcdir/Misc/platform_triplet.c >conftest.out 2>/dev/null; then
  PLATFORM_TRIPLET=`grep '^PLATFORM_TRIPLET=' conftest.out | tr -d '    '`
  PLATFORM_TRIPLET="${PLATFORM_TRIPLET@%:@PLATFORM_TRIPLET=}"
  AC_MSG_RESULT([$PLATFORM_TRIPLET])
else
  AC_MSG_RESULT([none])
fi
rm -f conftest.out

But on FreeBSD, Misc/platform_triplet.c fails to compile:

vstinner@freebsd$ cc -E Misc/platform_triplet.c | grep '^PLATFORM_TRIPLET=' | tr -d ' '
Misc/platform_triplet.c:289:3: error: unknown platform triplet
  289 | # error unknown platform triplet
      |   ^
1 error generated.

Maybe we should explore the ./config.guess option:

vstinner@freebsd$ ./config.guess
x86_64-unknown-freebsd15.0

The commit d3899c1 of issue gh-67169 in 2015 introduced PLATFORM_TRIPLET variable and modified SOABI to use it. The change is part of Python 3.5.

Result of import sysconfig; sysconfig.get_config_var('SOABI'):

• Python 3.4: 'cpython-34dm'
• Python 3.5: 'cpython-35dm-x86_64-linux-gnu'

Since the point of the feature is to have different .so names for different platforms, i think:

• adding -darwin or wasm32-wasi is correct.
• the fact that nothing is added for FreeBSD is a (low-priority) bug. We can fix it in the future (for cpython-3XX files as well as abi3 ones).
• Windows uses .pyd instead; changing that would be a different feature.

🤖 New build scheduled with the buildbot fleet by @encukou for commit 0ebab06 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F152461%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

test_curses fails on RHEL8 buildbot workers, but these workers should only be run on Python 3.12 and older. Example: https://github.com/python/buildmaster-config/blob/519dfd6b9757ab889d32677b71c074c5ccc2096c/master/custom/workers.py#L115.

!buildbot FreeBSD14

🤖 New build scheduled with the buildbot fleet by @encukou for commit e59ddbc 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F152461%2Fmerge

The command will test the builders whose names match following regular expression: FreeBSD14

The builders matched are:

• AMD64 FreeBSD14 PR

Let's get it in then.

Thanks @stefanor for the PR, and @encukou for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15.
🐍🍒⛏🤖

GH-154772 is a backport of this pull request to the 3.15 branch.