«

On Sat, 12 Jul 2003 13:53:35 -0700, Tom Plunket paused, took a deep
breath, then came out with:

> I want to do something along the lines of the following C++ code:
>
> void change(int& i)
> {
> i++;
> }

> Is there any way to do references like this in Python?
<snip>

In Python, basic types like strings and numbers are a weird exception to
the 'everything is an object' rule.

When you pass any other object in a function, the function gets a ref to
that object.

But when you pass a string or numeric object, the whole thing (not a ref)
gets passed.

Your best bet would be to create a wrapper class for numbers, store the
actual number in an attribute, and provide all the methods in Section
3.3.6 of the Python Reference Manual (__add__, __sub__ etc) to work on the
value attribute.

That way, you can use your numeric object in calculations, and when you
pass it to functions (like your 'change()' above), things will work as
expected. In fact, in most situations, it will look/feel/smell just like
a number.

But watch out for trying to assign to it, or using '+=' type operators -
they will replace your object with a plain number.

I attach below a sample class declaration for a numeric type which is
passable by reference (no need to do this for string, since you can just
use the UserString module).

Cheers
David

class myint:
def __init__(self, value):
self.value = value

def __getattr__(self, attr):
if attr in ['__repr__', '__add__', '__repr__', '__add__',
'__sub__', '__mul__', '__floordiv__', '__mod__',
'__divmod__', '__pow__', '__lshift__',
'__rshift__', '__and__', '__xor__', '__or__',
'__div__', '__truediv__', '__radd__', '__rsub__',
'__rmul__', '__rdiv__', '__rtruediv__',
'__rfloordiv__', '__rmod__', '__rdivmod__',
'__rpow__', '__rlshift__', '__rrshift__',
'__rand__', '__rxor__', '__ror__',
'__neg__',
'__pos__', '__abs__', '__invert__',
'__complex__', '__int__', '__long__',
'__float__', '__oct__', '__hex__', '__coerce__']:
return getattr(self.value, attr)

def __iadd__(self, other):
self.value += other
return self.value

def __isub__(self, other): self.value -= other
def __imul__(self, other): self.value *= other
def __idiv__(self, other): self.value /= other
def __itruediv__(self, other):
self.value = self.value.__itruediv__(other)
def __ifloordiv__(self, other): self.value = self.value.__itruediv__(other)
def __imod__(self, other): self.value = self.value.__imod__(other)
def __ipow__(self, other): self.value = self.value.__ipow__(other)
def __ilshift__(self, other): self.value = self.value.__ilshift__(other)
def __irshift__(self, other): self.value = self.value.__irshift__(other)
def __iand__(self, other): self.value = self.value.__iand__(other)
def __ixor__(self, other): self.value = self.value.__ixor__(other)
def __ior__(self, other): self.value = self.value.__ior__(other)

On Sun, Jul 13, 2003 at 10:58:13PM +1200, David McNab wrote:
> On Sat, 12 Jul 2003 13:53:35 -0700, Tom Plunket paused, took a deep
> breath, then came out with:
>
> > I want to do something along the lines of the following C++ code:
> >
> > void change(int& i)
> > {
> > i++;
> > }
>
> > Is there any way to do references like this in Python?
> <snip>
>
> In Python, basic types like strings and numbers are a weird exception to
> the 'everything is an object' rule.
>
> When you pass any other object in a function, the function gets a ref to
> that object.
>
> But when you pass a string or numeric object, the whole thing (not a ref)
> gets passed.

Numbers and strings are objects just like everything else in Python and
are passed by reference. The only difference is that they are *immutable*
objects so their value cannot be changed through that reference in a way
that will be visible to others who reference the same object. Under most
circumstances a reference to an immutable object is nearly indistingishable
from a value. But the id() builtin function or the 'is' operator quickly
reveal the difference.

There is no weird exception to any rule here. Some objects are mutable,
some are not. That's all.

Oren

"David McNab" <postmaster@127.0.0.1> wrote in message
newsan.2003.07.13.10.58.11.376531@127.0.0.1...
> In Python, basic types like strings and numbers are a weird
exception to
> the 'everything is an object' rule.

In Java perhaps, but NOT in Python. This is WRONG, WRONG, WRONG.
Please do not muddy the waters like this.

In Python, most builtin types are immutable. The two mutable builtin
types are lists and dicts. Instances of user-defined classes are also
mutable by default.

>When you pass any other object in a function,
>But when you pass a string or numeric object, [incorrect statement
clipped]

In Python, everything is 'passed' to functions the same way: first,
the argument expressions are evaluated one at a time, left to right.
In the typical case (number of argument expressions == number of
positional parameters), the resulting objects are then bound to the
corresponding parameter names, left to right, in the local namespace
of the function. (Or, if you prefer, the names are bound ...) The
type of the argument objects is not looked at.

How a particular interpreter performs name binding is its own
business, as long as the specified semantics are implemented. What
CPython does may or may not be the same as Jython or any other actual
or potential computer implementation. What any computer does is
probably significantly different from what human interpreters do.

Terry J. Reedy

On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
> The fact is that 'assignment' has a common meaning separate from the
> choice of programming language,

This just isn't true. The C++ assignment operator is not at all like
the Python assignment statement. Python variables are not like C++
variables, no surprise assignment is different too. If you used
languages outside of C++ and its like (e.g., Pascal), you would find
Python's behavior common.

(Admittedly, some confusion may occur because these very different
operations use the same syntax:

x = 10
x[0] = 10
obj.x = 10

The second and third are entirely different from the first.)

Ian

David McNab wrote:

> In Python, basic types like strings and numbers are a weird exception to
> the 'everything is an object' rule.
>
> When you pass any other object in a function, the function gets a ref to
> that object.
>
> But when you pass a string or numeric object, the whole thing (not a ref)
> gets passed.


This is completely incorrect. On the contrary, builtin types are
handled exactly uniformly in Python. The only difference here is that
the builtin types that you've listed, along with some others, are
immutable, so you cannot change them if you have a reference to them.

Contrast this to, say, Java, where there really is a solid distinction
between builtin fundamental types, like int and long, and actual object
types, derived from java.lang.Object, which are all passed by reference.
Python doesn't make this distinction.


--
Erik Max Francis && && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ But who shall dwell in these worlds if they be inhabited?
\__/ Johannes Kepler

"Stephen Horne" <> wrote in message
news:...
> On Sun, 13 Jul 2003 15:07:23 -0400, "Terry Reedy" <>
> wrote:
>
> >How a particular interpreter performs name binding is its own
> >business, as long as the specified semantics are implemented.
>
> You could use the same argument to rationalise a language which used
> the + operator to express subtraction.

Bogus comparison with name binding. I am not aware that Python does
anything quite so backwards.

> The fact is that 'assignment' has a common meaning separate from the
> choice of programming language, and that the way Python handles name
> binding means that meaning is not respected by Python for mutable
> objects.

From what others have posted, Python is not the only language in which
'name=object' means "assign 'name' to that object". This is much
closer to the common idea of object having names than the idea that
names can only name value holders (blocks of linear memory) and not
values or objects themselves.

Terry J. Reedy

On Sun, Jul 13, 2003 at 03:05:38PM -0500, Ian Bicking wrote:
> On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
> > The fact is that 'assignment' has a common meaning separate from the
> > choice of programming language,
>
> This just isn't true. The C++ assignment operator is not at all like
> the Python assignment statement. Python variables are not like C++
> variables, no surprise assignment is different too. If you used
> languages outside of C++ and its like (e.g., Pascal), you would find
> Python's behavior common.
>

C++ is the only language that has the same semantics as C++.

I was a long time C++ guy and my a-ha moment was when I realized that the
GoF's "Design Patterns" were not all universal -- some are C++ specific.
Trying to force Python semantics into a C++ world view will leave you feeling
empty every time. Drink the koolaid, python has a short learning curve.
If this is a problem - whatever you do - DONT TRY TO LEARN LISP.

If you want a more polished C++, use Java. Python is in a different class
of languages.

-jack

On 13 Jul 2003 15:05:38 -0500, Ian Bicking <>
wrote:

>On Sun, 2003-07-13 at 14:39, Stephen Horne wrote:
>> The fact is that 'assignment' has a common meaning separate from the
>> choice of programming language,
>
>This just isn't true. The C++ assignment operator is not at all like
>the Python assignment statement. Python variables are not like C++
>variables, no surprise assignment is different too. If you used
>languages outside of C++ and its like (e.g., Pascal), you would find
>Python's behavior common.

Think again.

When I say "'assignment' has a common meaning separate from the choice
of programming language" I assumed you would get the hint. I'm not
referring to some specific other programming language, of which I have
used many - and not all of them imperative. I am referring to the
definitions in computer theory, which do not relate to any specific
programming language but actually apply to all of them, irrespective
of paradigm and everything else.

Of course, if you really believe that pointer/reference behaviour
should be arbitrarily tied to mutability then you can claim that I am
wrong, but you still can't claim the high ground as this is still an
arbitrary and bizarre thing to do. The ability to change part or all
of a value in-place has nothing to do with whether that value is
referenced using a pointer or whatever in computer theory - any link
between pointers/references and mutability should be related to the
implementation of the language - not the semantics.

So much for dropping out of the discussion, but I hate it when people
make false claims about my beliefs, making me out to be ignorant, when
it is *not* *me* who is missing the point.

On Sun, 13 Jul 2003 17:16:08 -0400, "Terry Reedy" <>
wrote:

>> You could use the same argument to rationalise a language which used
>> the + operator to express subtraction.
>
>Bogus comparison with name binding. I am not aware that Python does
>anything quite so backwards.

Using an exaggeration as an analogy. Possibly. Though terms like
'assignment', 'variable' and 'value' seems pretty fundamental to me,
so the exaggeration is not that huge.

>> The fact is that 'assignment' has a common meaning separate from the
>> choice of programming language, and that the way Python handles name
>> binding means that meaning is not respected by Python for mutable
>> objects.
>
>From what others have posted, Python is not the only language in which
>'name=object' means "assign 'name' to that object". This is much
>closer to the common idea of object having names than the idea that
>names can only name value holders (blocks of linear memory) and not
>values or objects themselves.

Many languages have *explicit* ways to create what computer science
calls pointers. Sometimes they have implicit dereferencing. Sometimes
they come prepackaged in a 'pointer to' or 'reference to' style
object. But the fact that you are dealing with something that
semantically behaves as a pointer is always explicit in some way or
another.

Or rather, it should be. The fact that a few other languages are
broken in much the same way does not mean that Python is doing the
right thing. The right thing does not mean imitating Java or whatever
any more than it means imitating C++.

If you want a good example to imitate, though, look to Haskell. I
don't know how it binds variables to values, but I do know that in
general it can't a simple mapping from identifier to memory location.
Even so, I don't care. Why should I? The implementation of the binding
is irrelevant - I only care that the value bound to the variable is
the one that I specified and that it doesn't get changed behind my
back.

Stephen Horne <> writes:

> >This just isn't true. The C++ assignment operator is not at all like
> >the Python assignment statement. Python variables are not like C++
> >variables, no surprise assignment is different too. If you used
> >languages outside of C++ and its like (e.g., Pascal), you would find
> >Python's behavior common.
[...]
> The ability to change part or all
> of a value in-place has nothing to do with whether that value is
> referenced using a pointer or whatever in computer theory - any link
> between pointers/references and mutability should be related to the
> implementation of the language - not the semantics.

So you think "assignment" is about "changing values"? This is the case
in C and C++, but not the case in Java (atleast for objects), and Python.

In Python, assignment changes variables, not values. This is something
fundamentally different. In Python (and many other languages),
variables are independent of their value (and vice versa). Variables
are *associated* with a value, instead of *being* that value. Then,
assignment changes that association - not the value itself.

> So much for dropping out of the discussion, but I hate it when people
> make false claims about my beliefs, making me out to be ignorant, when
> it is *not* *me* who is missing the point.

I'm uncertain what your point is, however, I do observe that computer
theory has a different view of what assignments are than what I think
your view is.

Regards,
Martin