A Bug By Any Other Name ...
Terry Reedy
tjreedy at udel.edu
Mon Jul 6 15:55:02 EDT 2009
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
More information about the Python-list
mailing list