On 11/18/2012 10:32 PM, Mike Meyer wrote:

I've got three reasons to not do that:

Special cases aren't special enough to break the rules. Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. Except, python uses normal getopts style parsing for its own arguments.

Simply declare this to be the meaning of the previously undefined 'space' option flag. Nothing special, not an error if it's defined, and not ambiguous.

If you knew you were handling a shebang line, it might be different. But if a user went out of their way to pass those arguments on the command line, you want to be very careful about undoing what they did. Undoing what? We're not talking about an option to a script, we're talking about an option ('\x20') to the python interpreter that has no other meaning. And it's not an error anymore that it is defined.

The only other possible meaning of an argument beginning with '-' and containing a space is e.g. '-m mod' using the (undocumented, I might add) syntax of following the option directly with its argument to load a module called '\x20mod' (can module names even begin with a space?) Alternately, we could introduce a special syntax to allow additional interpreter options to be set within the file. I also note that the -W, -Q, -m, and -c options already violate the principle of requiring all options to be able to be specified in a single argument to the interpreter, as would be required to allow all combinations of options to be able to be specified on a shebang line on such a system. The more compelling case for not using a long option is simply that python does not use any other long options, not any logic about saying that all combinations of options must be able to be specified on a shebang line.

On 11/18/2012 10:32 PM, Mike Meyer wrote:

I've got three reasons to not do that:

Special cases aren't special enough to break the rules. Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. Except, python uses normal getopts style parsing for its own arguments.

Simply declare this to be the meaning of the previously undefined 'space' option flag. Nothing special, not an error if it's defined, and not ambiguous.

If you knew you were handling a shebang line, it might be different. But if a user went out of their way to pass those arguments on the command line, you want to be very careful about undoing what they did. Undoing what? We're not talking about an option to a script, we're talking about an option ('\x20') to the python interpreter that has no other meaning. And it's not an error anymore that it is defined.

The only other possible meaning of an argument beginning with '-' and containing a space is e.g. '-m mod' using the (undocumented, I might add) syntax of following the option directly with its argument to load a module called '\x20mod' (can module names even begin with a space?) Alternately, we could introduce a special syntax to allow additional interpreter options to be set within the file. I also note that the -W, -Q, -m, and -c options already violate the principle of requiring all options to be able to be specified in a single argument to the interpreter, as would be required to allow all combinations of options to be able to be specified on a shebang line on such a system. The more compelling case for not using a long option is simply that python does not use any other long options, not any logic about saying that all combinations of options must be able to be specified on a shebang line.