why cannot assign to function call

Aaron Brady castironpi at gmail.com
Sun Jan 11 08:27:48 EST 2009


On Jan 10, 1:49 pm, Joe Strout <j... at strout.net> wrote:
> Aaron Brady wrote:
> >> Aaron Brady wrote:
> >>> Possible compromise.  You can think of functions as mutation-only.
> >>> You pass the object, and it gets a new (additional) name.  The old
> >>> name doesn't go in.  </compromise>
> >> That's correct.  The reference itself is passed in, not the variable (or
> >> expression) that held or generated the reference in the calling code.
>
> > This is very odd, and I see it quite a bit.
> > Me: "You pass the object."
> > Joe: "That's correct.  You pass the reference."
>
> > What was wrong with my original?
>
> I'm saying that I believe your idea was correct, but worded imprecisely
> (IMHO of course).  So I restated what I believed you were saying, using
> terminology which I believe to be more precise.  If nothing else, this
> gives you the opportunity to say "No, that's not what I meant at all."

I believe that my summary is exceedingly beginner-oriented, you might
say colloquial.  Someone who has even a little programming experience
might find it childish.

> >> This is true.  (Technically, instead of variable, we should say "LValue"
> >> here -- there are things slightly more complex than simple variables
> >> that can serve as the left-hand side of an assignment.  So replace
> >> "variable" with "lvalue" above if you prefer.)
>
> > This is a point worth making.  I want to penny-pinch every term in an
> > introductory text, though, so, it's a tough call.
>
> Agreed.

Is a function call an lvalue in Python?  If not, descriptors are not
functions.

> >> M2: If 'fun()' returned a reference, you might be able to mutate the
> >> object that refers to.
> >> m2: You can sometimes mutate the object it refers to.
> >> C2: 'fun()' returns a reference.
>
> > This is horrendous.
> >http://en.wikipedia.org/wiki/Formal_fallacy
> >http://en.wikipedia.org/wiki/Affirming_the_consequent
>
> I did point out that the logic was incorrect (even though the
> conclusion, in this case, happens to be true).-

You've done nothing other than restate your claim; and worse, you
disguised doing so in the form of a deduction.

> > A question: Are you Joe and you Mark certain that the simplest
> > possible introductory explanation makes use of the term 'reference'?
>
> I am.

In any explanation, there is an amount of detail omitted.  In an
introduction, it's large.  (I hold false statements should be avoided,
of course, and even misleading ones.  However the latter is widely
subject-dependent.)  Your strategy may have a net positive unifying
power, though; and we should see it if so.  I may be asking whether it
is safe and prudent to avoid (introducing) the term at the level we're
looking at (as well as what level exactly it is).

> > Perhaps we can have a contest for shortest/simplest/best description
> > of Python's data/variable/argument model.
>
> Sure -- but it judging it might be difficult, requiring some newbies and
> a test to check their comprehension (as you and I pondered once before).

I think the step of least load would be to ask those who are having
difficulty what their background is.  At worst, they lie; next worst,
there's no pattern.

> > Lastly, I don't see any reason why we couldn't make both explanations
> > available.  'For those coming from Java/etc....; for those coming from
> > C++/etc.....'  They would both get read.
>
> Yes, except that the reference explanation applies equally well to
> anyone coming from Java, C/C++, RB, VB.NET, and probably others... I'm
> not sure to whom the other explanation would appeal, unless perhaps it's
> LISP programmers (just a guess, since those on that side of the aisle
> seem to invoke LISP more frequently).

True or not, it requires the reader to know what references are.  And,
since your definition conflicts with the C++ definition, it's not
clear that the requirement is good.

More terminology: is 'a' a variable, a reference, or an object, in
'a=2'?

It's a variable; it refers to an object.
It's a variable, which refers to an object.
It's a variable, which is a reference to an object.
It's a reference to an object.

Similarly, is '2' an expression, a reference, or an object?

It's an expression; it evaluates to an object.
It's an expression; it evaluates to a reference to an object.
It's an expression; it expresses an object.
It's an expression; it refers to an object.
It's a reference to an object.
It's an object.

I'd like to recommend we decide on unique answers, or avoid ambiguity
another way.

<digression>
In the case of the Socratic, non-bludgeoning, dialogue with a student,
if the student can be trusted to question intelligently, s/he can be
expected, on our telling him/er, "'a' is an object", to ask, "What
object?"  Whether to expect audience interaction, and what
interaction, is a big component in the choice of method of a
demonstration.
</digression>

<digression>
>>> 300+301+302 is 300+301+302
False

There are 10 objects created in the evaluation of this, 11 if
including 'False'.  They (their integer contents), in order, are: 300,
301, 302, then 300, 301, 302, not the same ones, again, then 602, 903,
602, 903, and then possibly 'False' *.

* Based on a run of a build of 'r26:66714' with extra output from
'PyInt_FromLong' and command line '-c "300+301+302 is 300+301+302"'.
Actual output showed 624 int objects created (!) with this function
alone, ending with: 300 301 302 300 301 302 11788072 8192 11788072 601
903 601 903!  Any ideas about those extra three?
</digression>



More information about the Python-list mailing list