On Fri, 30 May 2014 17:19:00 +1000, Chris Angelico wrote:
> On Fri, May 30, 2014 at 4:20 PM, Steven D'Aprano
> <steve+comp.lang.pyt...@pearwood.info> wrote:
>>> It's on par with creating a file with a name beginning with a hyphen,
>>> and then fiddling around with various commands as you try to
>>> manipulate it (tip: "rm ./-r" works); programs will happily interpret
>>> "-r" as an option rather than a file name, without being concerned
>>> that it's technically legal.
>>
>> I don't see any connection between the two.
>
> -r is a valid file name, just as . is a valid line of input. But with
> the rm command, you can't provide it with -r as a file name - you have
> to use ./-r or somesuch, because the parser gets to it first. That's the
> connection.
The analogy doesn't quite match, because rm, like all shell commands,
does it's own argument parsing, whereas Python operators do not. But
putting that aside, the parser's rule is "arguments starting with a dash
are treated as options". That's *standard behaviour*. If you want to
override that standard behaviour, you have to tweak the command:
rm -f ./-r /tmp/*
Some commands accept a single dash to mean "no more options following
this". Assuming rm does the same:
rm -f - -r /tmp/*
Either way, it is the standard behaviour as defined by rm, and so
expected. That makes this the equivalent of Python's rule that dot
behaves somewhat like an operator, and that a dot on its own is legal any
place a bare binary operator is legal.
The analogy to "the REPL is allowed to modify standard syntax to make a
bare dot special" would be something like:
the shell is allowed to pre-process the command line, so
that -r on a line on its own like this:
rm -f \
-r \
/tmp/*
which otherwise would have been treated as `rm -f -r /tmp/*`,
is instead turned into `rm -f ./-r /tmp/*`.
Reading the rm man page won't tell you this, because it happens outside
of rm, just as reading the Python documentation won't tell you about the
tricks your hypothetical REPL does to otherwise legal syntax. rm doesn't
know what tricks your hypothetical shell might do, and neither can the
Python parser tell what tricks your hypothetical REPL might do. Both see
only what the shell give them.
This is why I'm so adamant that, while REPLs may be permitted to
introduce *new* syntax which is otherwise illegal to the Python parser,
(e.g. like IPython's %magic and !shell commands) they *must not* change
the meaning of otherwise legal Python syntax. It's simply a bad idea to
have legal Python code mean different things depending on what
environment you're running it in.
(As I mentioned before, the annoying "blank line closes all open blocks"
rule gets an exception simply because I don't believe there is any
practical alternative.)
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
