gh-121249: deprecate support for complex types 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 #32520150 | 📁 Comparing ec9cf6b against main (3efd2f4)

  🔍 Preview build  

8 files changed · ± 8 modified

± Modified

• deprecations/index.html
• deprecations/pending-removal-in-3.17.html
• library/struct.html
• whatsnew/3.12.html
• whatsnew/3.13.html
• whatsnew/3.14.html
• whatsnew/3.15.html
• whatsnew/changelog.html

[hugovk]

Any reason to rush this and not use the recommended five years?

https://peps.python.org/pep-0387/#making-incompatible-changes

[skirpichev]

Yes, this was intentional.

I see some reasons:

1. This was introduced recently, I don't expect much breakage.
2. This is a minor feature.
3. I hope, it might be addressed by new PEP, that modernize the struct module and/or finish incomplete proposals of the PEP 3118.
4. If no PEP will come - probably it's not that important ;-)

As an alternative, we could consider part of the Victor's PR #148676: use Zf/Zd codes per default and add F/D as aliases, for backward compatibility. But IMO, PEP is better.

[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.