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 #32536160 | 📁 Comparing 344d2be against main (3efd2f4)

  🔍 Preview build  

21 files changed · ± 21 modified

± Modified

• c-api/lifecycle.html
• c-api/stable.html
• c-api/synchronization.html
• deprecations/index.html
• deprecations/pending-removal-in-3.19.html
• deprecations/pending-removal-in-3.20.html
• library/argparse.html
• library/array.html
• library/calendar.html
• library/ctypes.html
• and 11 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.

[skirpichev]

@vstinner, deprecation was reverted.