From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] app/argparse: expect no value for a boolean option
Date: Mon, 11 Nov 2019 23:25:44 +0100 [thread overview]
Message-ID: <686ed898-91d1-546e-6120-ed7b1f46e1d7@tarantool.org> (raw)
In-Reply-To: <c5ad5ef9e4aecd36d9feb3bb076ceae401d3e1db.1573259560.git.alexander.turenko@tarantool.org>
Hi! Thanks for the patch!
See 3 comments below.
On 09/11/2019 01:39, Alexander Turenko wrote:
> Before commit 03f85d4cfffbd43dccef880525cb39e56e967ae1 ('app: fix
> boolean handling in argparse module') the module does not expect a value
> after a 'boolean' argument. However there was the problem: a 'boolean'
> argument can be passed only at end of an argument list, otherwise it
> wrongly consumes a next argument and gives a confusing error message.
>
> The mentioned commit fixes this behaviour in the following way: it still
> allows to pass a 'boolean' argument at end of the list w/o a value, but
> requires a value ('true', 'false', '1', '0') if a 'boolean' argument is
> not at the end to be provided using {'--foo=true'} or {'--foo', 'true'}
> syntax.
>
> Here this behaviour is changed: a 'boolean' argument does not assume an
> explicitly passed value despite its position in an argument list. If a
> 'boolean' argument appears in the list, then argparse.parse() returns
> `true` for its value (a list of `true` values in case of 'boolean+'
> argument), otherwise it will not be added to the result.
>
> This change also makes the behaviour of long (--foo) and short (-f)
> 'boolean' options consistent.
>
> The motivation of the change is simple: it is easier and more natural to
> type, say, `tarantoolctl cat --show-system 00000000000000000000.snap`
> then `tarantoolctl cat --show-system true 00000000000000000000.snap`.
>
> This commit adds several new test cases, but it does not mean that we
> guarantee that the module behaviour will not be changed around some
> corner cases, say, handling of 'boolean+' arguments. This is internal
> module.
>
> Fixes #4076 (again).
1. Strictly speaking, it is not a fix, it is a follow-up. The bug is
fixed already.
> ---
>
> https://github.com/tarantool/tarantool/issues/4076
> https://github.com/tarantool/tarantool/tree/Totktonada/gh-4076-argparse-no-value-for-boolean-arg
>
> src/lua/argparse.lua | 59 +++++---
> test/app/argparse.result | 8 +-
> ...h-4076-argparse-wrong-bool-handling.result | 143 ++++++++++++++++--
> ...4076-argparse-wrong-bool-handling.test.lua | 60 +++++++-
> 4 files changed, 226 insertions(+), 44 deletions(-)
>
> @@ -108,13 +119,21 @@ local function parameters_parse(t_in, options)
> if key == nil or val == nil then
> error(("bad argument #%d: ID not valid"):format(i))
> end
> + -- Disallow an explicit value after '=' for a
> + -- 'boolean' or 'boolean+' argument.
> + if lookup[key] == 'boolean' or lookup[key] == 'boolean+' then
> + return err_bad_parameter_value(key, val, lookup[key])
> + end
> result_set_add(t_out, key, val)
> else
> if command:match("^([%a_][%w_-]+)$") == nil then
> error(("bad argument #%d: ID not valid"):format(i))
> end
> local val = true
> - do
> + -- Don't consume a value after a 'boolean' or
> + -- 'boolean+' argument.
> + if lookup[command] ~= 'boolean' and
> + lookup[command] ~= 'boolean+' then
2. Something is wrong with the indentation.
3. This check "type ~= boolean and type ~= boolean+" is repeated 3
times in this file now. I would add a function like 'type_has_value(type)'
or similar which would encapsulate it.
> -- in case next argument is value of this key (not --arg)
> local next_arg = t_in[i + 1]
> local is_long, is_short, is_dash = parse_param_prefix(next_arg)
next prev parent reply other threads:[~2019-11-11 22:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-09 0:39 Alexander Turenko
2019-11-11 22:25 ` Vladislav Shpilevoy [this message]
2019-11-12 17:40 ` Alexander Turenko
2019-11-12 20:41 ` Vladislav Shpilevoy
2019-11-12 21:03 ` Alexander Turenko
2019-11-12 21:33 ` Vladislav Shpilevoy
2019-11-13 4:33 ` Konstantin Osipov
2019-11-13 8:40 ` Alexander Turenko
2019-11-15 0:18 ` Alexander Turenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=686ed898-91d1-546e-6120-ed7b1f46e1d7@tarantool.org \
--to=v.shpilevoy@tarantool.org \
--cc=alexander.turenko@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH] app/argparse: expect no value for a boolean option' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox