Pass-by-reference : Could a C#-like approach work in Python?

Mel Wilson mwilson at
Thu Sep 11 23:47:42 CEST 2003

In article <mv_7b.215$o71.11 at>,
"Steve Holden" <sholden at> wrote:
>"Stephen Horne" <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$> wrote...
>> And if in some future version of Python the suggestion I made was
>> implemented, when you see f(x) you will still know that x cannot be
>> rebound - but when you see f(ref x) you will know that x may well be
>> rebound.
>OK, remind me why this is better than
>x = Inc(x)
>x, y = DoubleInc(x, y)

   My poster child here would be the idiom

        number, digit = divmod (number, base)

which is really handy in converting number to a
representation in some given base.  A different function
could simplify this (in a way) to

        digit = refdivmod (ref number, base)

but at the cost of a new function

        def refdivmod (ref a, b): ...

which, for all the duplication and the new keyword is *less*
capable than what we have, since we can use divmod for
everything refdivmod could do .. but not vice versa.

(A bit late, since everybody in the thread already agrees):     Mel.

   This seems like another case of a change that simplifies
some particular line of code, while spreading complication
throughout the rest of the language (new keywords, more
complexity hidden behind subroutine calls, non-obvious
namespace handling.)  I haven't been able to articulate this
opinion of mine well enough to expect it to stand up in a
newsgroup.  Gerald Weinberg's _The Psychology of Computer
Programming_ has some remarks on language design that may
help me out eventually.  Yet another discussion of removing
the 'self' parameter from class methods started me off.


More information about the Python-list mailing list