getopt should strip whitespace from long arguments

[stevendaprano]

BPO	27619
Nosy	@stevendaprano, @bitdancer, @berkerpeksag, @serhiy-storchaka
Files	getopt.patch getopt.patch getopdemo.c

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2017-03-07.18:47:43.456>
created_at = <Date 2016-07-26.00:50:17.323>
labels = ['invalid', 'type-feature', 'library']
title = 'getopt should strip whitespace from long arguments'
updated_at = <Date 2017-03-07.18:47:43.455>
user = 'https://github.com/stevendaprano'

bugs.python.org fields:

activity = <Date 2017-03-07.18:47:43.455>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2017-03-07.18:47:43.456>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2016-07-26.00:50:17.323>
creator = 'steven.daprano'
dependencies = []
files = ['43884', '43886', '43898']
hgrepos = []
issue_num = 27619
keywords = ['patch']
message_count = 13.0
messages = ['271310', '271319', '271320', '271321', '271322', '271323', '271359', '271361', '271378', '271395', '271400', '271403', '277201']
nosy_count = 4.0
nosy_names = ['steven.daprano', 'r.david.murray', 'berker.peksag', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue27619'
versions = ['Python 3.6']

[stevendaprano]

As reported here:

https://mail.python.org/pipermail/python-list/2016-July/711333.html

there's a possible annoyance with getopt when you accidentally leave whitespace on a long option. On my Centos system, getopt ignores leading and trailing whitespace on long options.

[steve@ando ~]$ getopt -o "" -l " spam , eggs " -- --spam --eggs arg
--spam --eggs -- 'arg'

Python's getopt should do the same. (Patch attached.)

[berkerpeksag]

I left some review comments on Rietveld. I think we can treat this as a bug and fix it in 3.5 too.

[stevendaprano]

Thanks for the quick review, I've fixed the issues you mentioned.

[serhiy-storchaka]

On my Centos system, getopt ignores leading and trailing whitespace on long options.

This is not related to how getopt_long in C works with leading and trailing whitespace on long options, but is related to how command-line utility getopt parses a list of long options.

My answer: if you don't want a space in your long_option, don't put a space in there. There is no a bug in Python, and the patch just complicates the code in attempt to fix one particular user error.

[stevendaprano]

On Tue, Jul 26, 2016 at 04:50:33AM +0000, Serhiy Storchaka wrote:

My answer: if you don't want a space in your long_option, don't put a
space in there. There is no a bug in Python,

That's why I listed it as an enhancement, not a bug.

and the patch just complicates the code in attempt to fix one
particular user error.

Sure. But the extra complexity is tiny, and the benefit is real, and it
makes Python getopt behave more like the shell getopt, which I think is
appropriate.

[serhiy-storchaka]

It makes Python getopt behave less like the C getopt.

[stevendaprano]

Serhiy Storchaka added the comment:

It makes Python getopt behave less like the C getopt.

Exactly! If C getopt allows whitespace in long options, it's a GOOD
thing to avoid such a poor design. Who would want a option --foo (note
the trailing space)?

[serhiy-storchaka]

Who would want options --f o o, --f�oo, or --fоо?

[bitdancer]

I agree with Serhiy. Python is a programming language, not a shell. It seems to me that it should not be second guessing a constant specified by the programmer. If the programmer puts spaces in the specification string, Python should respect that. I have no idea why one would do that, but such an option *can* be specified in the command line invocation, even using the shell. And yes, misspecifying a constant is a common source of program bugs, but I think, as Serhiy pointed out, it would be worse to have some "obvious nonsense" fixed but not others.

Now, would we want to enhance getopt to validate the longopts in a more general way and raise an error? I'm not sure it is worth the effort, especially since getopt is explicitly emulating the C getopt, and it does not do so.

[stevendaprano]

On Tue, Jul 26, 2016 at 03:27:29PM +0000, R. David Murray wrote:
[...]

getopt is explicitly emulating the C getopt

There are lots of differences between the C getopt and the Python
version, and the Python version is described as offering an API
"designed to be familiar" to uses of the C version, not to emulate all
the idiosyncrasies of the C version. For instance, the Python version
raises an exception on errors, rather than returning -1; the C version
requires argc ("argument count"), but the Python version doesn't.

But most critically, the C version DOES strip whitespace from long
arguments. On my Centos box, it only strips *trailing* spaces, not
leading spaces, but it does strip them. So if your argument is that we
must do what the C getopt does, then we must likewise at least strip
trailing spaces.

Attached is a demo, adapted from the code given by man 3 getopt.

[steve@ando ~]$ gcc getopdemo.c
[steve@ando ~]$ ./a.out "-- spam" 1 --eggs 2 "-- cheese" 3
option spam with arg 1
option eggs with arg 2
option cheese with arg 3

If Serhiy is going to insist that getopt.py must follow the C getopt
precisely, then the failure to strip trailing spaces is certainly a bug.

[serhiy-storchaka]

C getopt doesn't strip trailing spaces. What you mistook for stripping trailing spaces is actually a feature of GNU getopt that allows you to use shortened variant of long option.

$ ./getopdemo "--  sp" 1 --eg 2 "--  ch" 3
option   spam   with arg 1
option eggs   with arg 2
option   cheese with arg 3

[bitdancer]

I realized some time after I posted that my comment about it emulating C getopt needed a gloss. What I meant was that C getopt is the model, so there should be a sufficient argument that adding a feature is worthwhile. You are making that argument, but Serhiy and I disagree that it is worthwhile, or consistent with the fact that Python is a programming language and not a shell.

We may be in the minority, though, for all we know.