gh-95461: Add some parameters in CreateKeyEx and OpenKeyEx in winreg

[aisk]

• Issue: [winreg] support options and opened disposition in CreateKeyEx and OpenKey[Ex]  #95461

[zooba]

Looks good, and I'd appreciate having the extra option there! Just need those audit events reverted - I don't think we need new ones.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[zooba]

Nearly there! Most important thing now I think is updating the real docs in Doc\library\winreg.rst.

[zooba]

We should probably document the interaction with reserved here. I'm not sure what the history is of reserved becoming a meaningful parameter, but it's meaningful now, so we should say that here (and in the real docs, Doc\library\winreg.rst). (I mean "here" as in a few lines above, but I can't comment on it because it hasn't been updated yet).

[serhiy-storchaka]

We could make all optional parameters keyword-only. If there are many optional parameters, passing positional arguments is error-prone.

Also, imagine the code that calls CreateKeyEx(key, sub_key, options, access) was executed in the old Python version. It will silently ignore the third argument.

[aisk]

Hi, I updated and changed the newly added reversed to keyword-only. Change all the optional parameters to keyword-only should be in another PR I think?

[aisk]

Hi, I just noticed that currently winreg.OpenKey is just an alias of winreg.OpenKeyEx instead of a direct wrapper of the Windows's RegOpenKey for some reason. Should we keep this, or just change it by don't add the new options parameter on it?

[zooba]

Hmm... perhaps we would be better to look at this as a stepping stone to replacing the reserved name with options in both cases? Something like this:

• in 3.14, rename reserved to options and add reserved as keyword only
• show a deprecation warning if reserved is non-zero (i.e. it was provided by name)
• remove reserved in 3.16

And keep OpenKey the same. RegOpenKey is deprecated by the OS, so we want to be calling the new one (even though the old one likely won't ever go away, and is probably doing the same thing we are). It's already a direct alias, so no need to change anything.

[serhiy-storchaka]

I think it is worth to make all new parameters keyword-only. Their order differs from the order in RegCreateKeyExW(), so passing them as positional arguments will be errorprone.

We can also deprecate passing reserved (which should not be here at first place) and access by keyword, but this is a different issue.

[aisk]

Hi, thank you for the review. I made the newly added parameters options and create_only keyword-only-ed.

[serhiy-storchaka]

We could make all optional parameters keyword-only. If there are many optional parameters, passing positional arguments is error-prone.

Also, imagine the code that calls CreateKeyEx(key, sub_key, options, access) was executed in the old Python version. It will silently ignore the third argument.