how much does Python model my Compsci course?

Alex Martelli aleaxit at
Wed Jun 6 11:02:45 CEST 2001

"Fredrik Lundh" <fredrik at> wrote in message
news:E4kT6.2150$G4.322952 at
> Roy Katz wrote:
> > But Python looks as if it has invented a new form to (perhaps a
> > variation on pass-by-ref) param passing, based on whether or
> > not the object passed in is mutable (from what I understand...?)
> no, you don't understand ;-)
> the *only* difference between mutable and immutable objects is
> that the former have methods that let *you* modify them.
> Python doesn't care.

/F is impeccable and succing as usual, but (being verbose as
usual) I thought I'd add one caveat to his note about "Python
not caring" for the difference between mutable and immutable
object (impeccable in terms of argument-passing, but maybe
slightly overbroad as more-generally stated)... Python "doesn't
care" about mutable/immutable distictions, _except_...

...except that it's free to optimize, if & when it wants, by
reusing an existing immutable-object, rather than generating a
new one that would be equal to the existing one, when it's
convenient for it to notice such reusability.  It currently
only does that in a few cases, which is why sometimes one
gets peculiar results when playing with the 'is' operator
(that tests identity rather than equality):

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Alternative ReadLine 1.4 -- Copyright 2001, Chris Gonnerman
>>> 4 is 2+2
>>> 400 is 200+200

the number 4 is 'reused' as above (small int's are, in this
specific implementation), number 400 isn't (in this specific
implementation -- one's code should *NOT* depend on that, as
next implementation might decide to reuse 400 too, or to stop
reusing 4, or...:-).

Therefore, one uses '==', NOT 'is', on immutable objects
(with the exception of specific single-identity objects
such as None or NotImplemented), to avoid falling afoul of
such optimizations.  (For *MUTABLE* objects, the distinction
between '==' and 'is' should hopefully be sharp and clear
enough so that one runs no such risks:-).

But, of course and to reiterate, this is not relevant to
argument-passing in particular... it's a general issue:-).
So, nothing /F said is wrong -- I'm just expanding a bit:-).


More information about the Python-list mailing list