why no ++?

Quinn Dunkan quinn at retch.ugcs.caltech.edu
Mon Aug 6 17:47:49 EDT 2001


On 06 Aug 2001 14:27:29 -0400, Christopher A. Craig <com-nospam at ccraig.org>
wrote:
>>    There should be on--and preferably only one--obvious way to do things.
>> 
>
>Hmm.  I think I disagree.  If we had i++ (only the postfix version),
>then the obvious way to do:
>
>   i+=1
>   func(i)
>
>would become
>
>   func(i++)

That wouldn't be obvious to a C, Java, or Perl programmer.  I think they would
be surprised if `func(i++)' were not equivalent to `func(i); i+=1'.

>I had always thought the reason for not having i++ was because, in
>general, each line of Python code can have at most one lvalue.
>
>To state that another way, if something modifies a value it does not
>generally also return a value.  This is evidenced by the following not
>returning values:

Yeah, that's a generally good practice in most imperative languages.  It's
good to keep mutating procedures and non-mutating functions clear in your
mind.  Eiffel calls this "call query seperation".

>In fact the only exceptions I can think of to this rule (in the core
>language) are as follows
>
>dict.popitem()
>dict.setdefault(key, value)
>list.pop(index)
>several 'file' methods

Eiffel goes even further with this, for example:

fp.read_line
s := fp.last_string

I haven't decided yet if this consistency is of the hobgoblin variety or not.

>two operations separately.  I don't feel than i++ over i+=1 offers
>this sort of significant benefit, so I would lobby against it being
>added.

Agreed.  Even without the post/pre confusion, it offers too litle
bang-for-buck.



More information about the Python-list mailing list