why cannot assign to function call

[Mark Wooding]

[Steven's message hasn't reached my server, so I'll reply to it here.
Sorry if this is confusing.]

Aaron Brady <castironpi at gmail.com> wrote:
> On Jan 8, 1:45 am, Steven D'Aprano
> <ste... at REMOVE.THIS.cybersource.com.au> wrote:
> > On Wed, 07 Jan 2009 10:17:55 +0000, Mark Wooding wrote:
> >
> > > The `they're just objects' model is very simple, but gets tied up in
> > > knots explaining things.  The `it's all references' model is only a
> > > little more complicated, but explains everything.
> >
> > But it *over* explains, because it implies things that "everybody knows"
> > about references in other languages that aren't true for Python.

I addressed this elsewhere.  Summary: `pass-by-reference' is a different
thing to `all you manipulate are references': Python does pass-by-value,
but the things it passes -- by value -- are references.

(The `pass-by-*' notions are confusingly named anyway.  Pass-by-name
doesn't actually involve names at all.)

> > Of course it's not literally true that "everybody knows" that you
> > can use references to implement a swap(x, y) procedure. But people
> > coming from a C or Pascal background tend to assume that everything
> > is like C/Pascal, and there are a lot of them. If C was a rare,
> > unfamiliar language, my opposition to using the term "reference"
> > would be a lot milder. Maybe in another five years?

I agree with the comment about Pascal, but C is actually pretty similar
to Python here.  C only does pass-by-value.  If you want a function to
modify your variable, you have to pass a pointer value which points to
it.  Python has no pointer values, so you need a different hack.  The
hack usually involves lists.  (Though it's easier in the main to return
compound data objects like tuples.  I don't suppose that a proposal for
true multiple return values would go down well here.  No, didn't think
so...)

> > Okay, the abstraction has leaked again... are the paperweights references
> > to the objects, or the names we've bound objects to? I'm confused...

They're the references to the objects.  You don't bind names to
objects.  You bind names slots in which you store references.

This discussion -- I'd call it an argument, but that might give the
wrong impression, because I think we're being remarkably civil and
constructive by the standards of Usenet arguments! -- hasn't started on
the topic of variable bindings or environments yet.

> > How do we deal with anonymous objects in your model?
> >
> > --
> > Steven
> 
> Mark, hi, Steven, pleasure as always.

Hello. ;-)

> Neither side is perfect or wild; (Do admit it); 

It's true.

> How do we decide what is best for newcomers to Python, depending on
> background?

That I really don't know.  I'm not good at teaching total beginners
(does it show?) because I'm too enmired in the theory.  (It doesn't help
that I go off on tangents about how language X does something similar
but subtly different all the time, though my rich background comes in
very useful all over the place and that's something I think is worth
sharing.)

It probably doesn't help that I came to Python with a thorough
understanding of Scheme (among many others) under my belt, because many
Scheme concepts carry over directly, including the data model (it's all
references) and the variable model (nested, mutable, lexical
environments with closures).

What I am pretty sure of is that references are going to have to enter
the picture at some point, because other models get too complicated.

Oh, while I remember: the `distributed Python' model, with auto-updating
copies, only works for sharing.  Circular structures still require
actual references or a Tardis.

-- [mdw]