[issue39467] Allow to deprecate CLI arguments in argparse

[hervé]

hervé  added the comment:

hello,

First thanks everyone to took time to discute about this proposal.

This topic is now opened since ~1 months so I don't think we will more feedback 
about this, then I will address all your comments in my changes soon to match 
an implementation more consensually based.

--
nosy: +4383

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

In general I agree with Raymond, although I am warmer to this feature. And I 
think we should have a mechanism to deprecate not only options, but subcommands.

* The warnings module is used for warning about the use of API. It outputs the 
file and the line number of the caller to help the developer to fix his code. 
It allows to hide warnings from non-developers.

But warnings about deprecated CLI options and commands are purposed to be shown 
to the user of the CLI. They should not contain references to source code, 
because it is not the cause of the warning. The argparse module should use the 
same mechanism for warnings and errors: output to stderr.

* I do not understand the purpose of deprecated_pending. The feature is either 
deprecated or not. If it is deprecated, using it will produce a warning. If it 
is not deprecated -- no warning. In case of silent deprecation you can manually 
add a note in the help.

* I am not sure about deprecated_reason. We do not have a way to specify error 
message for standard errors (such like about missed required argument). If you 
need a custom warning, do not use the standard deprecation mechanism and emits 
a warning manually.

* As for moving the output of a warning to post-parsing logic, this is not 
always convenient and possible.

Let you have options "--verbose" which increments the verbosity level and 
"--verbosity-level" which sets it directly. One of them is deprecated. We can't 
easily use a post-parsing logic because they set the same destination. In this 
case we can workaround this by rewriting the logic to use different 
destinations, but there this is not always possible. Imagine you have options 
--add and --append which append the argument to the list and want to deprecate 
one of them. You can't use different lists and merge them in post-parsing, 
because the relative order matters.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[hai shi]

hai shi  added the comment:

IMHO, cli should only support atomic function.What is atomic functin? (if 
downstream software's feature can not keep alive without upstream fucntion, it 
must be an atomic function).

--
nosy: +shihai1991 -4383

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[hervé]

hervé  added the comment:

First, thanks Raymond for your worth useful comment.

* Concerning the usage of the warning module what do you suggest to use then?  
To use "print"? 

* Concerning "hook or flag" and the 3 new params in my PR, I think developers 
would appreciate to give a customized message to their users to inform that 
something will be removed for X reasons in the X release. The "pending" notion 
could be removed to keep the API lightweight, but with a well documented 
feature I don't seen terrible thing to understand here, maybe we need to put 
more effort on documentation and example (related to my changes).

* Concerning the fact to move deprecation management outside the declaration of 
the argument, I think it could be misleading to deprecate something in another 
place in the code, in other words it could introduce some more difficulties to 
understand the code. If the deprecation is declared in the argument declaration 
then all the info are centralized in one place and the parser know what to do 
in this situation.

Thoughts?

--
nosy: +4383

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[Raymond Hettinger]

Change by Raymond Hettinger :


--
Removed message: https://bugs.python.org/msg360813

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Will leave this open for a while so that many people can comment on the 
proposal before we act on it.

My initial take is:

* Having a way to deprecate seems useful.

* In practice, I haven't seen this done very much (in big tooling such as GCC 
perhaps, but everyday command-line tools don't seem to do this AFAICT).

* The warnings module is likely not the right implementation tool.  The 
warnings module doesn't make as much sense for CLIs as it does for libraries.  
In particular, the warnings module is all about the ability of consumer code to 
filter, ignore, or escalate warnings.  Also, we've so far been good about 
minimizing inter-module dependencies so that start-up time remains fast.

* The PR is aggressive in providing *deprecated*, *deprecated_reason*, and 
*deprecated_pending*.  Perhaps a simpler hook or flag would suffice.  The 
overall module API is already large enough to be a barrier to learning all the 
features.

* There is some question as to whether this belongs in argparse at all or 
whether it should be in downstream, post-parsing logic.  For example:

parser.add_argument('--throw', action='store_true',
 help = '(deprecated use "toss" instead) causes ball to move')
...
args = parser.parse_args()
if args.throw:
 print('"throw" has been deprecated, use "toss" instead',
   file=sys.stderr)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Will leave this open for a while so that many people can comment on the 
proposal before we act on it.

My initial take is:

* Having a way to deprecate seems useful.

* In practice, I haven't seen this done very much (in big tooling such as GCC 
perhaps, but everyday command-line tools don't seem to do this AFAICT).

* The warnings module is likely not the right implementation tool.  The 
warnings module doesn't make as much sense for CLIs as it does for libraries.  
It particular, the warnings module is all about the ability of consumer code to 
filter, ignore, or escalate warnings.  Also, we've so far been good about 
minimizing inter-module dependencies so that start-up time remains fast.

* The PR is aggressive in providing *deprecated*, *deprecated_reason*, and 
*deprecated_pending*.  Perhaps a simpler hook or flag would suffice.  The 
overall module API is already large enough to be a barrier to learning all the 
features.

* There is some question as to whether this belongs in argparse at all or 
whether it should be in downstream, post-parsing logic.  For example:
 
args = parser.parse_args()
if args.throw:
 print('"throw" has been deprecated, use "toss" instead',
   file=sys.stderr)
..

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +djarb, paul.j3, rhettinger -4383

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[hervé]

Change by hervé :


--
keywords: +patch
pull_requests: +17585
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18208

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39467] Allow to deprecate CLI arguments in argparse

[hervé]

New submission from hervé :

Today it's not possible to deprecate CLI arguments designed with argparse, it 
could be useful to introduce deprecation feature in argparse to allow 
developers to inform their apps's users when an argument is planed to be 
removed in the future.

--
components: Library (Lib)
messages: 360786
nosy: 4383
priority: normal
severity: normal
status: open
title: Allow to deprecate CLI arguments in argparse
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com