[Python-ideas] On evaluating features [was: Unpacking iterables for augmented assignment]

[James Lu]

> Rather,
>
because Python has become a big and very complete programming
>
environment, and a fairly large language, implementing new syntax
>
requires that a feature increase expressiveness substantially.
That makes sense.

> By comparison,
>   x, y += a, b
>
is neither more expressive, nor easier to read, nor significantly
>
harder to type, than
>
>

  x += a
>
    y += b
I agree. I contend that x, y += func(...) is more readable than the three-
statement alternative with a namespace pollution.


On Tue, Aug 28, 2018 at 4:05 AM Stephen J. Turnbull <
turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:

> Executive summary:  Much of this is my opinion, and as a newer poster,
> your opinion is *more* valuable than mine (fresh eyes and all that).
> What I hope you'll take from this post is a more precise understanding
> of the customary criteria that are used in evaluating a proposed
> feature on python-ideas and python-dev.
>
> Apologies for breaking the thread, but per Subject it's not really part
> of the thread.
>
> James Lu writes:
>
>  > I could, but I don't think that justifies not having this
>  > functionality in python standard.
>
> What's "this"?  Note:
>
>  >> When replying, please edit your Subject line so it is more specific
>  >> than "Re: Contents of Python-ideas digest..."
>
> I had to edit the Subject.  I'm going to assume you mean
>
>  >> 1. Re: Unpacking iterables for augmented assignment (Matthew Einhorn)
>
> So.  The Python development community generally doesn't require
> justification for refusing to implement new functionality.  Rather,
> because Python has become a big and very complete programming
> environment, and a fairly large language, implementing new syntax
> requires that a feature increase expressiveness substantially.
>
> In the case in point, the destructuring assignments
>
>     a, b = b, a
>     w, x, y, z = z, w, y, x
>
> can be interpreted as "swapping" or "permuting", and AIUI that's why
> they were included.  They express the intent better than
>
>     tmp = a
>     a = b
>     b = tmp
>     del tmp
>
> and I don't want to even think about how to do the 4-variable version
> without 4 temporary variables.  By comparison,
>
>     x, y += a, b
>
> is neither more expressive, nor easier to read, nor significantly
> harder to type, than
>
>     x += a
>     y += b
>
> as far as I can see.  Note that this is the "not harder to type"
> criterion normally used in discussing new Python features, not
> something I've invented.
>
>  > This is something I think most students will expect while learning
>  > python, especially if they're implementing algorithms.
>
> I suppose this claim is unlikely to be accepted without testimony of
> several teachers of Python.  In my own experience, I explicitly teach
> my students that the destructuring assignment is *for* permuting, and
> I have *not even once* been asked if it works for augmented
> assignments.  By contrast, students with knowledge of other languages
> (especially C-like languages) invariably "just use" augmented
> assignments and ask if there's some spelling for increment and
> decrement expressions.  Obviously, my teaching approach biases the
> result, but if nobody ever overcomes that bias, I do not think it is
> an expected or needed feature.
>
> Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180830/974e7796/attachment-0001.html>