Repository navigation
Argument Clinic: add support for deprecating positional use of parameters #95065
Description
Activity
If there is sufficient support for this feature, I'll create a PR.
If there is sufficient support for this feature, I'll create a PR.
TwoThree thumbs up; I'll create the PR 😎I'd suggest to go full
warnings._deprecatedon it, with an error if the specified removal version has reached beta without the change.Reacted by Erlend E. AaslandI'd suggest to go full
warnings._deprecatedon it, with an error if the specified removal version has reached beta without the change.Maybe I'm misunderstanding you, but that would imply extending the new syntax with optional deprecated version and removed version fields, right?
I think it is great idea, although I would like to use something more distinguishable and searchable than just
x.We should consider more general problem, when we want to change parameters in incompatible way.
- Turn positional-or-keyword parameters into keyword-only parameters. A directive which means "the following positional-or-keyword parameters will be keyword-only parameters in future".
- Turn positional-or-keyword parameters into positional-only parameters. A directive which means "the preceding positional-or-keyword parameters will be positional-only parameters in future".
- Remove parameter. For some converters we can use NULL or something like to distinguish absent argument, but for others all values after conversion are correct, so we need a special directive for this. When remove positional-only or positional-or-keyword parameter, all following parameters should become keyword-only parameters.
- Rename positional-or-keyword or keyword-only parameters. In meantime the function should accept both old and new keyword names, but raise an exception if both are passed or if the argument is passed as positional and keyword. For example see Wrong keyword parameter name in regex pattern methods #64482.
There may be other possible incompatible changes, but these four are common.
Reacted by Erlend E. Aasland and Oleg IaryginReacted by Erlend E. Aasland and Oleg IaryginI think it is great idea, although I would like to use something more distinguishable and searchable than just
x.Thanks for the support! I'm up for any other symbol;
xwas just the first thing that popped up in my head when I did the first proof-of-concept implementation. OTOH,*and/are not very searchable either.We should consider more general problem, when we want to change parameters in incompatible way. [...]
There may be other possible incompatible changes, but these four are common.
+1 However, I think we should create separate issues for each feature :)
Thanks for suggesting this! This would be nice, e.g. for #56166
A quick bikeshed, do we need to use a new symbol? Something like the following seems pretty readable:
posonlyarg / futureposonlyarg /-in-future posorkwarg *-in-3.12 futurekwonlyarg * kwonlyargOver here
*-in-3.12is a suggestion for how we could specify we wantwarnings._deprecatedsemantics.do we need to use a new symbol?
I don't know; I just picked that path, because it was very easy to implement as a proof of concept :)
Regarding the proposed extended format: I'd replace the hyphens with single whitespace to make it more readable.
cc. @colorfulappl: this might be of interest to you.
18 remaining items
- added 6 commits that reference this issue
on Aug 8, 2023 @erlend-aasland, do you mind to create issues for other two problems mentioned in #95065 (comment)? I could do them, but I am not sure about syntax.
@erlend-aasland, do you mind to create issues for other two problems mentioned in #95065 (comment)? I could do them, but I am not sure about syntax.
I'll get to it right away.
I think we can close this now. The only thing missing is the preprocessor tests; I'm not sure it is worth it to add all the boilerplate code needed to get such tests up and running. If we feel it is needed, we can create a follow-up issue for that particular item, but I don't think it should keep blocking the resolution of this issue.
Reacted by Serhiy StorchakaThanks again, to everyone involved!
Reacted by Alex Waygood
Feature or enhancement
Suggesting to add syntax for producing deprecation warnings for positional use of optional parameters.
I made a proof-of-concept patch for this where I introduced a new special symbol
x. Example use:This will then generate code that emits a DeprecationWarning if
optargis passed as a positional argument, but not if it is passed as a keyword.We can use this feature to introduce deprecation warnings for parameters that will become keyword-only in future releases. When the deprecation period is done, we can simply replace the
xwith*, to really make the optional params keyword-only.Pitch
Quoting @serhiy-storchaka, in issue #93057:
Previous discussion
Linked PRs