Why should I switch to Python?

Robert Getter rgetter at usa.net
Sat May 13 02:28:29 EDT 2000


In article <ycAS4.22098$oI2.45871 at afrodite.telenet-ops.be>, ben at co.and.co 
says...
> Charlie Derr <charlie at intelligenesis.net> wrote:
> > [Tim Peters]
> > ~
> > ~ [Grant Griffin]
> > ~ > Speaking of C, I find myself missing the "x=" operators, and "++".
> > ~ > However, I understand and endorse the reasons Python omits them.
> > ~
> > ~ While ++ makes little sense in a language with immutable numbers,
> > 
> > I'm probably missing something obvious here, but why?
> > 
> > The only weird part that i see is that in order to implement it you would
> > have to do a type check and make sure the operand is of type integer, which
> > certainly seems to violate python's spirit, but I don't understand what's
> > relevant about numbers being immutable.   I never write "5++" it's always
> > "varName++", which can obviously be done the long way with "varName =
> > varName + 1".   Couldn't this be implemented with assignment in this
> > fashion?  (not that i would want it to be done, i'm just curious)
>  
> There will be some surprises:
> 
> def malicious_print(i):
> 	i++
> 	print i
> 
> malicious_print(5) # Huh?
> b = 5
> malicious_print(b)
> print b		   # Huh?
> 
> Greetings,
> 
What surprise? If i++ is interpreted as i=i+1, then there is no problem. 
The altered version of the variable is local:

	>>> malicious_print(5)
	6
	>>> b = 5
	>>> malicious_print(b)
	6
	>>> print b
	5

The real problem arises when you have a user defined object.

If you want an object that changes state in response to a ++, this won't 
work right since there may be several references to a particular object:

	a = myobj()  # instantiate a user defined object
	b = a        # a and b are references to the same object
	b++          # causes b to point to a new object. a is untouched

One way to do it would be to read i++ as i=i+1 only for immutable types. 
For all other types, require that the developer implement a __postinc__ 
method.

This can certainly work, one problem I can think of right now is the 
proliferation of methods which would need to be defined:
	__postinc__()
	__preinc__()
	__postdec__()
	__predec__()
	__pluseq__()
	__subeq__()
	__muleq__()
	__diveq__()
etc.

Another problem is the inconsistency where integers, strings, 
tuples, and other immutables behave differently in some cases from all 
other types. Fortunately, they still behave the way most people expect 
them to.
-- 
Rob Getter



More information about the Python-list mailing list