gh-121249: remove F/D type codes from table in the struct module

[skirpichev]

• Issue: Add support for C99 complex type (_Complex) to the struct module #121249

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33323752 | 📁 Comparing 2da1b85 against main (3efd2f4)

  🔍 Preview build  

212 files changed · + 5 added · ± 207 modified

+ Added

• c-api/slots.html
• deprecations/pending-removal-in-3.21.html
• howto/abi3t-migration.html
• library/asyncio-threading.html
• whatsnew/3.16.html

± Modified

• bugs.html
• glossary.html
• index.html
• py-modindex.html
• c-api/bytes.html
• c-api/complex.html
• c-api/concrete.html
• c-api/coro.html
• c-api/dict.html
• c-api/exceptions.html
• and 197 more...

[serhiy-storchaka]

What is the reason for deprecation? Also, why is it linked to an issue closed long time ago?

[skirpichev]

What is the reason for deprecation?

It's an alternative to #148676, see python/steering-council#345 (comment)

There are 3 PRs:

• gh-148675: Revert GH-146237 and GH-146241 #148674
• this
• gh-61103: use PEP 3118 codes in the ctypes #149344

Also, why is it linked to an issue closed long time ago?

Reopened, thanks.

[encukou]

I'm -1.

@hugovk any objections to deprecating in a later beta, rather than b1? That would mean we don't need to decide now.

[skirpichev]

I removed F/D types from the table and postponed removal to 3.20. I think it's now along line of using two-letters type codes in the array, ctypes and for memoryvieweverywhere.

CC @vstinner

Edit: Alternatively - we could just drop old type codes from the table (no deprecation).

[vstinner]

It's too late to introduce a deprecation in Python 3.15. We can reconsider a deprecation in Python 3.16.

[vstinner]

I would like to hear the Steering Council opinion on this question.

[skirpichev]

I would like to hear the Steering Council opinion on this question.

@vstinner, what does require SC decision on this? It's regular documentation change, no deprecations.

[skirpichev]

CC @warsaw as SC voice in python/steering-council#345, per Victor's request.

[vstinner]

I created the issue python/steering-council#352 for the Steering Council to "Deprecated F and D format in the struct module in Python 3.16".

[vstinner]

Hi, the SC decision is to soft deprecate in Python 3.15 and deprecate in Python 3.16: python/steering-council#352 (comment) Currently, the PR does soft deprecate in Python 3.16.

Do you want to create a Python 3.15 PR to soft deprecate and a Python 3.16 to deprecate?

[skirpichev]

Currently, the PR does soft deprecate in Python 3.16.

No, it does this for v3.15 entry. I'll add news entry and then this will be ready for a backport.

I'll do a separate pr for v3.16 one something like this (soft-deprecation) will be merged.

[vstinner]

No, it does this for v3.15 entry. I'll add news entry and then this will be ready for a backport. I'll do a separate pr for v3.16 one something like this (soft-deprecation) will be merged.

I see that the soft deprecation must be documented in What's New In Python 3.15 document which is also part of the main branch, so ok, it makes sense :-)

[vstinner]

LGTM

[miss-islington-app]

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

[miss-islington-app]

Sorry, @skirpichev and @vstinner, I could not cleanly backport this to 3.15 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 5f17434a1ec9a121eb38f71dc3d5809020b5fbb4 3.15

[bedevere-app]

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

[vstinner]

Thanks, I merged your PR to soft deprecate F and D type codes. I'm now waiting for your 3.16 change to (hard) deprecate these type codes :-)