Allow mixing attached and unattached values for a multiple-value option argument

[coolreader18]

In #5361 (comment):

-ez foo bar takes the z as the argument and assumes that an attached value and unattached values are not mixed, and stops parsing -e.

is there any way to. mix those? 😅

In my defense, it seems like this used to work in v2.0 - it's taken me a while to get around to updating rustpython to use clap v3 (and now, v4) and it seems like the default behavior changed. With:

// clap v2
Arg::with_name("m")
    .short("m")
    .takes_value(true)
    .allow_hyphen_values(true)
    .multiple(true)
    .value_name("module, args")
    .min_values(1)
    .help("run library module as script"),
// clap v4:
Arg::new("m")
    .short('m')
    .action(Append)
    .allow_hyphen_values(true)
    .num_args(1..)
    .value_name("module, args")
    .help("run library module as script")
    .trailing_var_arg(true),

in v2, rustpython -mquopri -d would parse the same as rustpython -m quopri -d, i.e. -m marking the end of interpreter flags and the start of script arguments (or, more specifically - -m somehow seemed to enable the trailing_var_arg property of the script arg, meaning that values_of("m").chain(values_of("script")) would get all the args as we wanted them. I'm realizing a good chunk of the next sentence is wrong, but also that I'm not sure exactly how it actually worked in v2). But in v3 and v4, the attached argument to -m seems to imply that -m is fully done parsing arguments, and -d is thus interpreted as a flag for rustpython, instead of for quopri. This is obviously a very niche use case when looking at it as mixing attached and unattached option values. But, this is all kinda a hack around a perhaps less niche use case, which is that we want -m to mark the end of all parsing and just slurp the rest of the command line into a list. You'll see I set trailing_var_arg on -m, despite that being a no-op for named options - that was something I tried while trying to debug this before I dug into the code to figure out why it was happening. Maybe setting trailing_var_arg on options could have this described effect?

This has turned I guess into a feature request, but I'll open this discussion in case there is a way around this, and probably end up making an issue anyway.

[epage]

Yes, as I mentioned in that linked discussion, this is not supported. As for what was supported in v2 vs v3, that is hard to speak to. v3's development went dark for a very long period of time with a lot of changes and its hard to trace everything back because of some of the chaotic nature of that development. Likely git bisect could help to identify the root change to see what the background was for it but that is likely to be a lot of work with how much changed.

[coolreader18]

Fair enough! I might look into modifying trailing_var_arg to work on options, but I'll open an issue for that.