Documentation build overview

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

  🔍 Preview build  

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

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

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.

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.

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

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

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

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.

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

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

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?

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.

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 :-)

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

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

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

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 :-)

FYI: #152309