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