Is 'everything' a refrence or isn't it?

[Terry Hancock]

On Fri, 06 Jan 2006 20:49:06 +1100
"Steven D'Aprano" <steve at REMOVETHIScyber.com.au> wrote:
> On Thu, 05 Jan 2006 22:18:39 -0600, Terry Hancock wrote:
> >> Consider this:
> >> 
> >> def do_nothing(x):
> >>     pass
> >> 
> >> huge_tuple = (None,) * 10000**4
> >> do_nothing(huge_tuple)
> >> 
> >> If Python made a copy of huge_tuple before passing it
> >to > the function, you would notice.
> > 
> > Which succinctly demonstrates precisely why a newbie
> > *should* be told that Python passes references instead
> > of values. 
> 
> "I don't like Chinese food, and pizza gives me gas. Let's
> have a burger," says I.
> 
> And Terry helpfully answers: "Pizza gives you gas? Well
> there you go then, that's precisely why we have to have
> Chinese food."

An annoyingly banal, off-topic, and incorrect analogy.

> I have never suggested that we should tell newbies that
> Python is call by value, and I deny that the only two
> possible choices for usefully describing Python's
> behaviour is by CBV and CBR. The fact that Terry could
> read this thread and still imagine that there is such a
> dichotomy is worrying.

I didn't say you did, and it's very worrying that you could
read my post and not understand that.  You want to get
tetchy? I can *be* tetchy, if that's what you want. ;-)

As far as I am concerned "call by object" which is what you
*did* propose implies "call by value" to anyone who is just
learning the language, and that is the audience we're
talking about.

I mean, *I* know what you mean when you say "Python is 'call
by object'" just as *you* know what I mean when I say
"Python is 'call by reference'", but where does that leave
Mr. Newbie?

Sorry, but the burgers give him gas, too.
 
> > But it should probably also be made clear that
> > "reference" means a label assigned to an object, and not
> > a variable containing a memory location (which is what a
> > C "pointer" is).
> > 
> > The reference is usually a simple name, but it can also
> > be an container expression following list, dictionary,
> > or class instance (spam, spam[0], spam['eggs'], or
> > spam.ham, for example).  Not tuple or string because
> > they are immutable, and so don't have assignable
> > references.
> 
> Are you seriously suggesting that you can't include tuples
> in a list, or pass them to functions? Because that's what
> it sounds like you're saying: "Python passes references.
> The reference is usually a simple name, but it can also be
> a container... Not tuple or string because they are
> immutable."
> 
> If you don't mean to say that Python can't pass strings to
> functions, what do you mean to say?

No, don't be intentionally thick.

I mean that you cannot dereference a string or tuple in
order to assign elements of them -- which is another way of
saying they are immutable.

> I'll tell you what I say: Python passes objects to
> functions or assignments.
> 
> Does this mean that the object is copied? No, I didn't say
> it copies objects. I left the nature of the passing
> mechanism unspoken, which is how it should be because it
> is an implementation detail.

And that is where we part ways, my friend. Because
"implementation details" do matter when they make a
difference between execution in 10 seconds and executions in
10 days.  Even a newbie is going to be hesitant to do things
that look like they are going to do the latter.  He still
needs to have a reasonably correct mental model of what his
program is going to do.

> Does this mean that the object can be modified in place?
> Certainly not, since that depends on the object, not on
> the nature of Python's high-level behaviour. It emphasises
> the object oriented nature of Python, and by its very
> language warns the reader not to assume that Python
> behaves identically to other languages. It invites further
> questions, rather than lulling the reader into jumping to
> false conclusions.

Chigaimasu! It just leads to *different* false conclusions.

> The emphasis is on the *object*, not the passing
> mechanism.[...]
> In Python, whether or not you can change an object depends
> on the object, not the language itself: it is a data
> issue.

True, but the passing mechanism still makes a difference in
understanding how Python programs operate.

Of course, this conversation is starting to get extremely
silly.

Terry

-- 
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com