L
Lawrence D'Oliveiro
I wonder how many people have been tripped up by the fact that
++n
and
--n
fail silently for numeric-valued n.
++n
and
--n
fail silently for numeric-valued n.
C
Chris Rebert
Given that C-style for-loops are relatively infrequent in Python and
are usually written using range() when they are needed, it's probably
not that prevalent a problem.
I suppose the lexer could be changed to make ++ and -- illegal...
Cheers,
Chris
S
Steven D'Aprano
What do you mean, "fail silently"? They do exactly what you should expect:
-5
So does the bitwise-not unary operator:
5
I'm not sure what "bug" you're seeing. Perhaps it's your expectations
that are buggy, not Python.
G
Gabriel Genellina
En Mon, 06 Jul 2009 00:28:43 -0300, Steven D'Aprano
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...
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...
G
Gary Herron
Gabriel said:
Well sure, it's not unreasonable to expect ++n and --n to behave as in
other languages, and since they don't, perhaps they should be listed as
a "Python gotcha".
But even so, it's quite arrogant of the OP to flaunt his ignorance of
the language by claiming this is a bug and a failure. It shouldn't have
been all that hard for him to figure out what was really happening.
Gary Herron
G
Gabriel Genellina
En Mon, 06 Jul 2009 03:33:36 -0300, Gary Herron
That depends on what you call a "bug". In his classical book "The art of
software testing", Myers says that a program has a bug when it doesn't
perform as the user expects reasonably it to do (not an exact quote, I
don't have the book at hand). That's a lot broader than developers like to
accept.
In this case, a note in the documentation warning about the potential
confusion would be fine.
That depends on what you call a "bug". In his classical book "The art of
software testing", Myers says that a program has a bug when it doesn't
perform as the user expects reasonably it to do (not an exact quote, I
don't have the book at hand). That's a lot broader than developers like to
accept.
In this case, a note in the documentation warning about the potential
confusion would be fine.
T
Tim Golden
Gabriel Genellina wrote:
[... re confusion over ++n etc ...]
The difficulty here is knowing where to put such a warning.
You obviously can't put it against the "++" operator as such
because... there isn't one. You could put it against the unary
plus operator, but who's going to look there?
I've wondered for a while whether it wouldn't be a good move
to include the official (or any other) Python FAQ into the
standard docs set. If we did, that would be the obvious place
for this piece of documentation, seems to me.
TJG
[... re confusion over ++n etc ...]
The difficulty here is knowing where to put such a warning.
You obviously can't put it against the "++" operator as such
because... there isn't one. You could put it against the unary
plus operator, but who's going to look there?
I've wondered for a while whether it wouldn't be a good move
to include the official (or any other) Python FAQ into the
standard docs set. If we did, that would be the obvious place
for this piece of documentation, seems to me.
TJG
L
Lawrence D'Oliveiro
Tim Golden said:
This bug is an epiphenomenon.
A
alex23
The difficulty here is knowing where to put such a warning.
You obviously can't put it against the "++" operator as such
because... there isn't one. You could put it against the unary
plus operator, but who's going to look there?
The problem is: where do you stop? If you're going to add something to
the documentation to address every expectation someone might hold
coming from another language, the docs are going to get pretty big.
I think a language should be intuitive within itself, but not be
required to be intuitable based on _other_ languages (unless, of
course, that's an objective of the language). If I expect something in
language-A to operate the same way as completely-unrelated-language-B,
I'd see that as a failing on my behalf, especially if I hadn't read
language-A's documentation first. I'm not adverse to one language
being _explained_ in terms of another, but would much prefer to see
those relegated to "Python for <x> programmers" articles rather than
in the main docs themselves.
C
Chris Rebert
This bug is an epiphenomenon.
Well, like I suggested, it /could/ be made an operator (or rather, a
lexer token) which just causes a compile/parse error.
Cheers,
Chris
J
John Machin
What fail? In Python, ++n and --n are fatuous expressions which
SUCCEED silently except for rare circiumstances e.g. --n will cause an
overflow exception on older CPython versions if isinstance(n, int) and
n == -sys.maxint - 1.
T
Terry Reedy
Gabriel said:
How would that help someone who does not read the doc?
S
Steven D'Aprano
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.
There are plenty of other languages other than Java and C. If we start
listing every feature of Python that's different from some other
language, we'll never end.
For what it's worth, Ruby appears to behave the same as Python:
$ irb
irb(main):001:0> n = 5
=> 5
irb(main):002:0> ++n
=> 5
irb(main):003:0> --n
=> 5
irb(main):004:0> -+n
=> -5
H
Hendrik van Rooyen
Terry Reedy said:
It obviously won't.
All it will do, is that it will enable people on this group,
who may read the manual, to tell people who complain,
to RTFM.
I agree that it would be a good idea to make it an
error, or a warning - "this might not do what you
think it does", or an "are you sure?" exception.
- Hendrik
P
pdpi
It obviously won't.
All it will do, is that it will enable people on this group,
who may read the manual, to tell people who complain,
to RTFM.
I agree that it would be a good idea to make it an
error, or a warning - "this might not do what you
think it does", or an "are you sure?" exception.
- Hendrik
I dunno. Specifically recognizing (and emitting code code for) a token
that's not actually part of the language because people coming from
other languages think it exists seems like the start of a fustercluck.
M
Mark Dickinson
Recent python-ideas discussion on this subject:
http://mail.python.org/pipermail/python-ideas/2009-March/003741.html
Mark
R
Rhodri James
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.
P
Pablo Torres N.
Yes, it's their problem if they don't read the docs.
 I agree that it would be a good idea to make it an
error, or a warning - "this might not do what you
think it does", or an "are you sure?" exception.
Â
- Hendrik
That would be even harder than adding a line to the docs. Besides,
the problem that Mr. alex23 pointed: "where do you stop?" would really
get out of hand.
T
Terry Reedy
Rather few, it seems.
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
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
L
Lawrence D'Oliveiro
Terry said:
And it is C that introduced "==" for equality, versus "=" for assignment,
which Python slavishly followed instead of keeping "=" with its mathematical
meaning and using ":=" for assignment.