misleading prefix ++

[LuciferLeo@gmail.com]

given i = 0,
I know i = i + 1 and i += 1 are all correct
but when I type:[color=blue][color=green][color=darkred]
>>> i++[/color][/color][/color]
the interpreter replies:
File "<stdin>", line 1
i++
^
SyntaxError: invalid syntax

so I get the idea that suffix ++ is invalid in python
but when I input:[color=blue][color=green][color=darkred]
>>> ++i[/color][/color][/color]
and the interpreter replies
0

Don't you think it is misleading when you expect a variable to
increment?

[Steve Holden]

Re: misleading prefix ++

LuciferLeo@gmai l.com wrote:[color=blue]
> given i = 0,
> I know i = i + 1 and i += 1 are all correct
> but when I type:
>[color=green][color=darkred]
>>>>i++[/color][/color]
>
> the interpreter replies:
> File "<stdin>", line 1
> i++
> ^
> SyntaxError: invalid syntax
>
> so I get the idea that suffix ++ is invalid in python
> but when I input:
>[color=green][color=darkred]
>>>>++i[/color][/color]
>
> and the interpreter replies
> 0
>
> Don't you think it is misleading when you expect a variable to
> increment?
>[/color]
Terribly. So stop expecting it to increment :)

Seriously, --i is also valid Python. Both expressions apply two unary
operators to a name. Would you have these become illegal, or start to
mean increment/decrement? Either change would break years of backwards
compatibility.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Love me, love my blog http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Fredrik Lundh]

Re: misleading prefix ++

LuciferLeo@gmai l.com wrote:
[color=blue]
> Don't you think it is misleading when you expect a variable to
> increment?[/color]

no. and in my experience, most people know that they cannot just type
random stuff into a computer and expect it to do what they want.

(have you figured out *why* this is valid syntax, and what it does to
your integer?)

</F>

[Tim Chase]

Re: misleading prefix ++

>>>>>++i[color=blue][color=green]
>>
>>and the interpreter replies
>>0
>>
>>Don't you think it is misleading when you expect a variable to
>>increment?
>>[/color]
>
> Terribly. So stop expecting it to increment :)
>
> Seriously, --i is also valid Python. Both expressions apply two unary
> operators to a name. Would you have these become illegal, or start to
> mean increment/decrement? Either change would break years of backwards
> compatibility.[/color]

It looks like Python behaves more consistantly than C/C++/Java :)
By adding plus/minus signs, you get consistant behavior:
[color=blue][color=green][color=darkred]
>>> x = 42
>>> +x[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> ++x[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> +++x[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> ++++x[/color][/color][/color]
42[color=blue][color=green][color=darkred]
>>> # ad infinitum[/color][/color][/color]

In C-like languages, you get

x: 42
+x: 42
++x: 43
+++x: invalid lvalue in increment -> compile fails
++++x: 45
+++++x: invalid lvalue in increment -> compile fails
++++++x: 48

(actually, g++ accepted this funky syntax, but gcc choked on it,
so linguistic sludge is more tolerable in C++ than in C)

Looks like the OP should be over on c.l.c++ griping about the
inconsistancy of the "unary +" and "unary -" operators ;)

-tkc
(still waiting for my brain to kick in on a Sat. morning...)

[Peter Otten]

Re: misleading prefix ++

LuciferLeo@gmai l.com wrote:
[color=blue]
> but when I input:[color=green][color=darkred]
>>>> ++i[/color][/color]
> and the interpreter replies
> 0
>
> Don't you think it is misleading when you expect a variable to
> increment?[/color]

You have been warned...

$ cat pp.py
i = 42
++i
print i
--i
$ pychecker pp.py
Processing pp...
42

Warnings...

pp.py:2: Operator (++) doesn't exist, statement has no effect
pp.py:4: Operator (--) doesn't exist, statement has no effect

....or you would have been, had you used the pychecker :-)

Now I'm not recommending
[color=blue][color=green][color=darkred]
>>> class Int(object):[/color][/color][/color]
.... def __init__(self, value=0):
.... self.value = 0
.... self.half = False
.... def __pos__(self):
.... if self.half:
.... self.value += 1
.... self.half = not self.half
.... return self
.... def __str__(self):
.... return str(self.value)
.... __repr__ = __str__
....[color=blue][color=green][color=darkred]
>>> i = Int()
>>> i[/color][/color][/color]
0[color=blue][color=green][color=darkred]
>>> ++i[/color][/color][/color]
1[color=blue][color=green][color=darkred]
>>> ++i[/color][/color][/color]
2[color=blue][color=green][color=darkred]
>>> i[/color][/color][/color]
2

which is slightly harder to fix than to break but gives some (weak)
motivation not to rule out multiple prefixed signs.

Peter

[Edward Elliott]

Re: misleading prefix ++

Peter Otten wrote:
[color=blue][color=green][color=darkred]
>>>> class Int(object):[/color][/color][/color]
[snip][color=blue]
> ... def __pos__(self):
> ... if self.half:
> ... self.value += 1
> ... self.half = not self.half
> ... return self[/color]
[snip][color=blue][color=green][color=darkred]
>>>> i = Int()[/color][/color][/color]

which leads us to:
[color=blue][color=green][color=darkred]
>>>> i[/color][/color]
> 0[color=green][color=darkred]
>>>> +i[/color][/color]
> 0[color=green][color=darkred]
>>>> +i[/color][/color]
> 1[color=green][color=darkred]
>>>> +i[/color][/color]
> 1[color=green][color=darkred]
>>>> +i[/color][/color]
> 2[/color]

Now that is absolutely lovely. Looks like it's time to join the ranks of
Perl and C with an Obfuscated Python Contest. ;)

--
Edward Elliott
UC Berkeley School of Law (Boalt Hall)
complangpython at eddeye dot net

[Carl Friedrich Bolz]

Re: misleading prefix ++

Edward Elliott wrote:[color=blue]
> Peter Otten wrote:[/color]

[snip]
[color=blue]
>
> Now that is absolutely lovely. Looks like it's time to join the ranks of
> Perl and C with an Obfuscated Python Contest. ;)
>[/color]

yes, please! and you get special points for programs that seem to do one
thing but do something totally entirely different :-).

Cheers,

Carl Friedrich