

PEP 0448 – Additional Unpacking Generalizations - rectangletangle
https://www.python.org/dev/peps/pep-0448/

======
mraison
Whenever I see a new feature proposal for a programming language, I like to
check how a language in the lisp family could solve the same problem with a
macro (not trying to point out who is better than who, it's just for fun). For
example, this 3-liner would get you the "multiple array unpacking" in clojure:

    
    
        (defmacro pep448 [f & args]
          (let [unpack? #(and (list? %) (= (first %) '$))]
            `(apply ~f (concat ~@(map #(if (unpack? %) (second %) [%]) args)))))
    

which can be used like this:

    
    
        (pep448 + ($ [2 3]) 4 ($ [5 6 7]))
        => 27
    

A bit verbose, so you probably wouldn't do it this way in real life.
Thankfully there are generally easier and more elegant ways to handle this
kind of situation.

------
aaronchall
The new answer to this old question: "How can I merge two Python dictionaries
in a single expression?" \-
[http://stackoverflow.com/q/38987/541136](http://stackoverflow.com/q/38987/541136)

~~~
kbd
I wonder why set operations were never supported for dictionaries.

a = b | c

makes perfect sense, vs:

a = b.copy()

a.update(c)

~~~
JoshTriplett
b|c for sets is commutative; b|c for dictionaries is not. | is not strictly
required to commute, but a | operator that does not commute is surprising
behavior, and Python doesn't favor surprising behavior.

~~~
kbd
Thanks! That's exactly what I figured was the reason.

Personally I'd have gone for the practicality beats purity side of things
here, but oh well.

~~~
azernik
I think this is a practicality concern; specifically, with regards to the UI,
and following the rule of least surprise to keep user (i.e. programmer)
confusion down.

------
jacobolus
Interesting that this is mentioned in the Misc/NEWS file, but not in the
“What’s New In Python 3.5?” document.

[https://hg.python.org/cpython/file/3.5/Misc/NEWS](https://hg.python.org/cpython/file/3.5/Misc/NEWS)

[https://docs.python.org/3.5/whatsnew/3.5.html](https://docs.python.org/3.5/whatsnew/3.5.html)

Relevant bug tracker issue is
[http://bugs.python.org/issue2292](http://bugs.python.org/issue2292)

Mailing list discussions:

[https://mail.python.org/pipermail/python-
ideas/2013-July/thr...](https://mail.python.org/pipermail/python-
ideas/2013-July/thread.html#21872)

[https://mail.python.org/pipermail/python-
ideas/2015-January/...](https://mail.python.org/pipermail/python-
ideas/2015-January/thread.html#31012)

[https://mail.python.org/pipermail/python-
dev/2015-January/th...](https://mail.python.org/pipermail/python-
dev/2015-January/thread.html#137814)

[https://mail.python.org/pipermail/python-
dev/2015-February/t...](https://mail.python.org/pipermail/python-
dev/2015-February/thread.html#138564)

~~~
notatoad
When "what's new in python 3.5" was posted here a couple days ago it was
mentioned that the document was terribly incomplete and not ready for public
consumption.

------
Redoubts
Being stuck on 2.7 is becoming a little more unbearable every day.

~~~
pekk
If you were happy with 2.5 a few years ago, why is it any more unbearable to
use 2.7 today?

~~~
Redoubts
>If you were happy with 2.5 a few years ago

Do you mean 9 years ago?

-e-

But the real answer to your question is because I keep running into problems
that have more elegant solutions in 3.x

~~~
pekk
There are plenty of problems that have more elegant solutions in other
languages. I don't see that it makes your life unbearable for other solutions
to be available.

~~~
marvy
Quirk of human psychology: you now know what you're missing. I have this
problem sometimes. When I remind myself that it's just a quirk of my own mind,
it sometimes helps.

------
mikelward
Finally!

I've long wanted to do

for server in (server1, server2, *other_servers):

Instead of

for server in [server1, server2] + other_servers

~~~
Too
Can't tell if you are sarcastic or not but to me the second line is much more
readable.

~~~
agumonkey
That's mostly subjective, (a,b, °c) is a tuple of a, b and the rest being the
sequence c. After reading a lot of lisp and ml, it's a bit less of a burden
than [a,b] + l, in the sense that [a,b] is declarative mixed with an
operation, while (a,b, °c) is one declarative. You might say `°` is an
operation too, but it lives at the metalevel, and it's still enclosed in the
(tuple-declaration).

------
allendoerfer
Looking forward to this. Nice feature, does exactly what you expect it to do.
I think, you would not even notice it if you had not tried to use the
unpacking operator in such a way and learned, that it was not possible.

More of these + performance, please, and I am happy with you, Python.

