A Bug By Any Other Name ...

[Terry Reedy]

Mark Dickinson wrote:
> On Jul 6, 3:32 am, Lawrence D'Oliveiro <l... at geek-
> central.gen.new_zealand> wrote:
>> I wonder how many people have been tripped up by the fact that
>>
>>     ++n
>>
>> and
>>
>>     --n
>>
>> fail silently for numeric-valued n.

Rather few, it seems.

> Recent python-ideas discussion on this subject:
> 
> http://mail.python.org/pipermail/python-ideas/2009-March/003741.html

To add to what I wrote in that thread: it is C, not Python, that is out 
of step with standard usage in math and most languages. --x = x; 1/1/x = 
x; non not a = a; inverse(inverse(f)) = f; etc. And ++x= +x = x 
corresponded to I(I(x)) = I(x) = x, where I is identity function.

In C as high-level assembler, the inc and dec functions are written as 
-- and ++ operators for some mix of the following reasons. 1) They 
correspond to machine language / assembler functions. 2) They need to be 
efficient since they are used in inner loops. Function calls have 
overhead. Original C did not allow inlining of function calls as best I 
remember. 3) They save keystrokes; 4) 2 versions that return pre and 
post change values are needed. My impression is that some opcode sets 
(and hence assemblers) have only one, and efficient code requires 
allowing direct access to whichever one a particular processor supports. 
Basic routines can usually be written either way.

These reasons do not apply to Python or do not fit Python's style.
Anyone who spends 15 minutes skimming the chapter on expressions could 
notice that 5.5. Unary arithmetic and bitwise operations has only +,-, 
and ~ or that the Summary operator table at the end has no -- or ++.

Terry Jan Reedy