Inheriting the @ sign from Ruby

[Alex Martelli]

"Simon B." <sbrunning at bigfoot.com> wrote in message
news:915l04$l3i$1 at nnrp1.deja.com...
> In article <Pine.GSO.4.21.0012121027001.14542-100000 at y.glue.umd.edu>,
>   Roy Katz <katz at Glue.umd.edu> wrote:
>
> > I've been programming in Python for three years now
> > and I understand only that passing an int or float is call-by-value,
> > otherwise it is call-by-reference
>
> Isn't that Java? It *certainly* isn't Python - *everything* is by
> reference in python. Unless I'm *really* confused...

Python and Java have identical argument-passing semantics
(well, except that Java has static compile-time constraints
on the types of actual vs formal parameters, of course).

Python does have a few more "immutable-types" than Java;
besides numbers and strings, that are immutable in both
languages, Python's tuples are immutable sequences (I do
not believe Java has anything like that), and Python's
instances may easily be made practically-immutable by
raising suitable exceptions in __setattr__ (not a very
frequently used possibility, admittedly), e.g:

class AlmostImmutable:
    def __init__(self, initiallyMutable=None, **attributes):
        self.__dict__.update(attributes)
        self._lock(not initiallyMutable)
    def _lock(onoff):
        self.__dict__['_AlmostImmutable__locked'] = onoff
    def __setattr__(self, name, value):
        if self.__locked: raise AttributeError, "instance is locked"
        self.__dict__[name] = value

inheriting by this mixin class can easily make your own
class-instances 'almost-immutable' (they CAN actually
be changed, via .__dict__ manipulations or use of the
provided ._lock(0) method, but 'normal' attempts at
changing them when 'locked' will raise AttributeError).


But the fact that a given 'thing' is not mutable does not
really affect the fact that a reference to it, rather than
a copy of its value, is what gets passed (in Java as well
as in Python).  Maybe showing this mixin class might help
light dawn in this regard -- clearly, the instances of
classes inheriting from this one have two states, locked
and not locked, they're (ersatz:-) immutable in the locked
state, yet when such instances are passed as arguments the
same, identical mechanism is clearly being used, whatever
their current state may be...

However, I suspect the key issue is that people believe
an argument is 'by reference' if and only if *assigning to*
(as opposed to: calling suitable methods on) that formal
argument will somehow affect something in the caller.  Since
such effects of 'assignment' to formal arguments never occur
in either Python or Java, it may be somewhat hard to convince
people that by-reference IS happening anyway -- that the
real issue is that the semantics they have in mind for
*assignment*, rather than what they have in mind for *argument
passing*, is what is really changed!-)


Alex