[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Steve Holden]

On Fri, Apr 27, 2018 at 8:19 PM, Tim Peters <tim.peters at gmail.com> wrote:

> [Lukasz]
> >> >  And that *is* a thing that you will have to explain to newbies when
> >> > they encounter it for the first time.
>
> ​Which they will presumably do either in class or by reading code. No
sensible instructor or course author is going to bring name-binding
expressions up until standard assignment has been thoroughly assimilated.
In my own teaching experience I observed that those used to static
languages took a little time to adapt to the indirection of Python's names,
but not long.
​


> ​[...]
>
> Sure.  What I wrote was shorthand for what's already been covered at
> length many times:  what a binding expression does is "easy to
> explain" GIVEN THAT someone ALREADY UNDERSTANDS how binding a name
> works.  The latter in fact seems difficult for a significant number of
> people to learn, but it's utterly unavoidable that they learn it if
> they're ever to write non-trivial Python programs.  That's been true
> since Python's first release.
>
> ​I was half-expecting someone to pop up and suggest only functional
programming as a means to avoid having to teach assignment ...
​


> Binding expressions would be introduced much later in any sane course.
> At THAT point, for students who haven't already dropped out, the
> semantics are darned-near trivial to explain:  it binds the name to
> the object the expression evaluates to (all of which they _already_
> understand by this point), and the value of the binding expression is
> that object (the only new bit).
>
> Unlike as for most other operators, you don't even have to weasel-word
> it to account for that a magical dunder method may change what ":="
> does.  As for the "is" operator, the meaning is baked into the
> language and can't be altered in the slightest.
>
>
> > So having one more way to do assignment WILL make it harder to
> > teach, not because it's that hard, but because it's one more thing to
> learn.
>
> ​But surely that depends on HOW MUCH of the language you aim to teach.
​Over the years Python has become a much more complex language, but it has
a fairly easily-identified subset that can act as a basis for building
useful programs. Some instructors avoided teaching comprehensions, but a
sensible course would try to ensure that students could understand the code
they were most likely to encounter "in the wild."

[
> ​...]
>
> You now, I think instructors like me are partly responsible. "is" is
> rarely
> > useful outside of comparing to singletons. Yet I use it early in
> instruction
> > to do checks on name binding and show things with mutablilty, etc....
> which
> > has the unfortunate side effect of making it seem like a more common
> > operator than it is.
> >
>
​I'd expand that to say that identity comparison is most useful for types
whose instances are all unique. For other types there's the unfortunate
impedance mismatch between identity and equality (which is user-definable
anyway).
​


> > I've even had students write code like:
> >
> > if x is 3:
> >
> > and thanks to interning, it appears to work!
>
> ​No, thanks to interning it DOES work. For interned values.​

​But instructors have to touch on implementation artefacts at times, and I
used to find it instructive to write the same code with two different
integer constants and ask why they gave different results. It certainly
helped people to master the semantics of assignment (as did the phrase
"Python never copies data on assignment").​

Yup, that's the real problem with "is":  its semantics are dead
> simple, but "but under exactly what conditions are `x` and `y` bound
> to the same object?" is intractable.  It seems to take a long time to
> get across the point, that the question itself is misguided.  A full
> answer requires delving into transient implementation details, which
> is counterproductive because they _are_ accidents of the
> implementation du jour.  What questioners need to be nudged into
> asking instead is for examples of when using "is" is thoroughly sane.
>

​I'd argue that without some knowledge of the potential pitfalls students
can't be expected to learn how to make that distinction.

regards
 Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180428/5b91d717/attachment-0001.html>