> Another note about the proposal: calling it "deprecated" seems odd,
> since the proposal is really just a general-purpose callback. argparse
> isn't generating the warning, your callback function would be doing it.
> Why name it "deprecated"? How is this different than the "action"
>
Le 09/08/2017 à 12:59, Ned Batchelder a écrit :
> OK, then on a more pragmatic note: why is it easier to write a callback
> than to write a simple if statement after the parsing? Generating help
> is complex, and a common task that is closely tied to the syntax of the
> options, so it makes
OK, then on a more pragmatic note: why is it easier to write a callback
than to write a simple if statement after the parsing? Generating help
is complex, and a common task that is closely tied to the syntax of the
options, so it makes sense for argparse to do it. Deprecation is
neither complex,
On 8/9/17 3:56 AM, Tarek Ziadé wrote:
> Hey,
>
> I don't think there's any helper to deprecate an argument in argparse
>
> Let's say you have a --foo option in your CLI and want to deprecate it
> in the next release before you completely remove it later.
>
> My first though on how to do this by
+1, but I would make "deprecated" either a warning, an exception or a
callable.
This way to create a simple deprecation, you just provide
DeprecationWarning('This will be gone in the next release'), or
ValueError('This has been removed in 2.X, use "stuff instead"') if you
decide it's gone for
Hey,
I don't think there's any helper to deprecate an argument in argparse
Let's say you have a --foo option in your CLI and want to deprecate it
in the next release before you completely remove it later.
My first though on how to do this by adding a new "deprecated" option to
