> 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...@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
>
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
