why no ++?

[Christopher A. Craig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Griffin <not.this at seebelow.org> writes:

> I'm not sure if anyone has explained the philosophical basis of "why no ++". 
> It's rooted in Tim Peters' maxim:
> 
>    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++)

Much like with dict.setdefault() the obvious way to do

   if dict.has_key(key):
     return dict[key]
   else:
     dict[key]=value
     return value

becomes

   return dict.setdefault(key, value)

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:

num=num+num2
num+=1
del list[i1:i2]
list.sort()
list.reverse()
list.append(item)
list.extend(item)
list.remove(item)
dict[key]=value
dict.update(dict)
dict.clear()

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

All of which are explicitly designed for a specific instance where
modifying and returning offers a significant benefit over doing the
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.


- -- 
Christopher A. Craig <com-nospam at ccraig.org>
Death comes to those who wait
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt

iEYEARECAAYFAjtu4ZEACgkQjVztv3T8pztIHQCbBo9o2q3fgbiTdl0NjYVve+9D
iCkAoKkM/cTQv6MK/DJKhrmcUe3OvCQH
=5hxz
-----END PGP SIGNATURE-----