A Bug By Any Other Name ...

[Rhodri James]

On Mon, 06 Jul 2009 10:58:21 +0100, Steven D'Aprano  
<steve at 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
>> <steve at 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.

-- 
Rhodri James *-* Wildebeest Herder to the Masses