gh-89039: call subclass constructors in datetime.*.replace

[eltoder]

When replace() method is called on a subclass of datetime, date or time, properly call derived constructor. Previously, only the base class's constructor was called.

Also, make sure to pass non-zero fold values when creating subclasses in various methods. Previously, fold was silently ignored.

• Issue: .replace functions in datetime do not call __new__ #89039

[eltoder]

@serhiy-storchaka This is a follow-up to #112921 to fix another issue. Would appreciate if you could take a look.

[serhiy-storchaka]

LGTM. I have only few style nitpicks.

[miss-islington-app]

Thanks @eltoder for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @eltoder for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @eltoder and @serhiy-storchaka, I could not cleanly backport this to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 46190d9ea8a878a03d95b4e1bdcdc9ed576cf3fa 3.12

[miss-islington-app]

Sorry, @eltoder and @serhiy-storchaka, I could not cleanly backport this to 3.11 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 46190d9ea8a878a03d95b4e1bdcdc9ed576cf3fa 3.11

[serhiy-storchaka]

Thank you for your contribution @eltoder. Do you mind to create a backport for 3.12?

[eltoder]

@serhiy-storchaka Thank you for merging. Can we just backport #112921? Then this will work automatically. Or should I write a version of this change that doesn't use argument clinic?

[serhiy-storchaka]

Usually we do not backport conversions to Argument Clinic and pure optimizations. Although if it is a straightforward backport that helps future backports, there may be exceptions.

But seems that this is not the case. There are some conflicts in backporting of #112921, so they may be not so trivial. It may be safer to not backport it.

[eltoder]

@serhiy-storchaka The conflicts were very easy to resolve. I did it here: #115344

But I get a complaint from CI that the ABI changed. Is that correct or a false positive?

[serhiy-storchaka]

It does not allow to merge the PR without sanction of the Release Manager.

[eltoder]

@serhiy-storchaka What would you recommend? The backport itself is trivial, but it does change the size of pyruntimestate. Does this really affect the ABI? I see that there were some updates to it on the 3.12 branch by @ericsnowcurrently after 3.12 was released: https://github.com/python/cpython/commits/3.12/Doc/data/python3.12.abi
Maybe pyruntimestate is not really a part of the ABI?

[ericsnowcurrently]

The backport itself is trivial, but it does change the size of pyruntimestate. Does this really affect the ABI? I see that there were some updates to it on the 3.12 branch by @ericsnowcurrently after 3.12 was released: https://github.com/python/cpython/commits/3.12/Doc/data/python3.12.abi
Maybe pyruntimestate is not really a part of the ABI?

Correct. The runtime state struct is strictly internal, so we do sometimes change the related (internal) ABI in bug fix releases.

[eltoder]

@ericsnowcurrently Do you think it is acceptable to change pyruntimestate to backport #112921? I used argument clinic and it added some new string constants.

[ericsnowcurrently]

I don't see a problem with it, but release manager makes the final decision.

[bedevere-app]

GH-131239 is a backport of this pull request to the 3.12 branch.