Rhodri James wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">On Mon,
06 Jul 2009 10:58:21 +0100, Steven D'Aprano
<st...@remove-this-cybersource.com.au> wrote:
On Mon, 06 Jul 2009 02:19:51 -0300, Gabriel Genellina wrote:
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
<st...@remove-this-cybersource.com.au> escribió:
On Mon, 06 Jul 2009 14:32:46 +1200, Lawrence D'Oliveiro wrote:
I wonder how many people have been tripped up by the fact that
++n
and
--n
fail silently for numeric-valued n.
What do you mean, "fail silently"? They do exactly what you should
expect:
++5 # positive of a positive number is positive
I'm not sure what "bug" you're seeing. Perhaps it's your expectations
that are buggy, not Python.
Well, those expectations are taken seriously when new features are
introduced into the language - and sometimes the feature is dismissed
just because it would be confusing for some. If a += 1 works, expecting
++a to have the same meaning is very reasonable (for those coming from
languages with a ++ operator, like C or Java) - more when ++a is a
perfectly valid expression. If this issue isn't listed under the
various
"Python gotchas" articles, it should...
The fact that it isn't suggests strongly to me that it isn't that common
a surprise even for Java and C programmers. This is the first time I've
seen anyone raise it as an issue.
Indeed, arguably it's a bug for C compilers to fail to find the valid
parsing of "++5" as "+(+5)". All I can say is that I've never even
accidentally typed that in twenty years of C programming.
But the C language specifically defines the tokenizer as doing a
max-match, finding the longest legal token at any point. That's how
many things that would otherwise be ambiguous are well-defined. For
example, if you want to divide two integers, given pointers to them, you
need a space between the slash and the start.
*p1/*p2 begins a comment, while *p1/ *p2 does a division
--
http://mail.python.org/mailman/listinfo/python-list
