D'Oliveiro<l...@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.
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...
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 5 >>> --5 # negative of a negative number is positive 5 >>> -+5 # negative of a positive number is negative
-5
So does the bitwise-not unary operator:
>>> ~~5
5
I'm not sure what "bug" you're seeing. Perhaps it's your expectations that are buggy, not Python.
> 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...
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...
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.
> 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...
> 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.
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.
> In this case, a note in the documentation warning about the potential > confusion would be fine.
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.
In message <mailman.2674.1246866966.8015.python-l...@python.org>, Tim Golden wrote:
> 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.
On Jul 6, 5:56 pm, Tim Golden <m...@timgolden.me.uk> wrote:
> Gabriel Genellina wrote: > > In this case, a note in the documentation warning about the potential > > confusion would be fine.
> 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.
D'Oliveiro<l...@geek-central.gen.new_zealand> wrote: > In message <mailman.2674.1246866966.8015.python-l...@python.org>, Tim Golden > wrote:
>> 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.
> 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.
On Jul 6, 12:32 pm, Lawrence D'Oliveiro <l...@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.
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.
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.
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:
> "Terry Reedy" <t...j@..el.edu> wrote: > > Gabriel Genellina wrote:
> > > In this case, a note in the documentation warning about the potential > > > confusion would be fine.
> > How would that help someone who does not read the doc?
> 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.
<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.
-- Rhodri James *-* Wildebeest Herder to the Masses
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
On Mon, Jul 6, 2009 at 07:12, Hendrik van Rooyen<m...@microcorp.co.za> wrote: > "Terry Reedy" <t...j@..el.edu> wrote:
>> Gabriel Genellina wrote:
>> > In this case, a note in the documentation warning about the potential >> > confusion would be fine.
>> How would that help someone who does not read the doc?
> 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.
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.
Mark Dickinson wrote: > On Jul 6, 3:32 am, Lawrence D'Oliveiro <l...@geek- > central.gen.new_zealand> wrote: >> I wonder how many people have been tripped up by the fact that
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 ++.
On Mon, 06 Jul 2009 17:54:35 +0100, Dave Angel <da...@ieee.org> wrote: > Rhodri James wrote: >> 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
You know, I've never had that come up either! My habit of sticking spaces around binary operators purely for legibility probably helped, but I'm still a bit boggled.
-- Rhodri James *-* Wildebeest Herder to the Masses
In message <mailman.2714.1246910113.8015.python-l...@python.org>, Terry
Reedy wrote: > ... it is C, not Python, that is out of step with standard usage in math > and most languages ...
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.
>>>> 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.
> 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.
Yes, there are plenty of languages other than Java and C, but the influence of C is admittedly huge in Python. Why do you think loops are called "for", conditionals "if" or "while", functions return via "return", loops terminate via "break" and keep going via "continue" and why is comparison written as "==", etc, etc? All of these are coming from C (or an even earlier language) and my point is that users are most of time correct when they assume that something will work the same way as in C.
So I'd think that putting a warning in a FAQ or a Python Gotchas list about ++n would be very useful for many users. And it does not imply that the differences from every other language should be documented in a similar fashion. Only C :)
Cheers, Daniel
> For what it's worth, Ruby appears to behave the same as Python:
Chris Rebert wrote: > On Mon, Jul 6, 2009 at 1:29 AM, Lawrence > D'Oliveiro<l...@geek-central.gen.new_zealand> wrote: >> In message <mailman.2674.1246866966.8015.python-l...@python.org>, Tim Golden >> wrote:
>>> 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. >> 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
There are edge cases (level: very rare) where you legitimately want to actually do that, e.g.:
On Tue, 07 Jul 2009 04:51:51 +0000, Lie Ryan wrote: > Chris Rebert wrote: >> On Mon, Jul 6, 2009 at 1:29 AM, Lawrence >> D'Oliveiro<l...@geek-central.gen.new_zealand> wrote: >>> In message <mailman.2674.1246866966.8015.python-l...@python.org>, Tim >>> Golden wrote:
>>>> 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. >>> 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
> There are edge cases (level: very rare) where you legitimately want to > actually do that, e.g.:
Not so rare. Decimal uses unary plus. Don't assume +x is a no-op.
Help on method __pos__ in module decimal:
__pos__(self, context=None) unbound decimal.Decimal method Returns a copy, unless it is a sNaN.
|
