6 ms·

PEP 0448 – Additional Unpacking Generalizations

aaronchall 11y ago
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 11y ago
  I wonder why set operations were never supported for dictionaries. a = b | c makes perfect sense, vs: a = b.copy() a.update(c)
  - JoshTriplett 11y ago
    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 11y ago
      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 11y ago
        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.
- asgard1024 11y ago
  Many years ago, I complained to myself that in Python something required two expressions instead of one. Later I understood - it is probably intentional. I think there a design guideline for Python that says roughly if you can create an operator/function with a combination of 2 or 3 operators, then it probably is not worth adding. This keeps standard library relatively small and easy to memorize. Many other language keep adding various flavors of operators (and types, too) despite the fact you can easily build one from another.
  - klibertp 11y ago
    Many languages disagree on that rule (2 or 3 operators not worth factoring). Or rather, there are very many different approaches to this problem in various languages. Take a look at Forth, APL, J and possibly Factor to see something radically different than anything you've ever seen (and yes, people do use these). Personally I find well-chosen names to help readability and may help avoid code duplication. There are 2 or 3 operator long things very much worth naming (see for example https://gist.github.com/piotrklibert/a0849f26523cad3d594e#file-refactoring-py-L44 https://gist.github.com/piotrklibert/a0849f26523cad3d594e#fi...). It's a style I call "modern literate," which tries to emulate "literate programming" without extra-language tools. Jeremy Ashkenas uses it in his works, most notably Underscore.js and Backbone.js: the code is simultaneously a manual and a tutorial. See: http://backbonejs.org/docs/backbone.html http://backbonejs.org/docs/backbone.html
    - asgard1024 11y ago
      I am aware of that, that's why I mention it (and I would add Perl and many Lisp-like languages to your list). I appreciate the path that Python took, though, because it keeps language small and orthogonal. There is lot of value in this approach, especially if you share code with someone outside of the project. > There are 2 or 3 operator long things very much worth naming I don't understand your example. But I am talking about functions that are part of the libraries (especially standard ones). How you refactor your code is a different matter.
Redoubts 11y ago
Being stuck on 2.7 is becoming a little more unbearable every day.
- geofft 11y ago
  That's the point, of course. (Not that I agree.)
- pekk 11y ago
  If you were happy with 2.5 a few years ago, why is it any more unbearable to use 2.7 today?
  - Redoubts 11y ago
    >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 11y ago
      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 11y ago
        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.
- saurik 11y ago
  We should backport all the good features from 3.x to 2.7: I bet it would only take a few days.
mikelward 11y ago
Finally! I've long wanted to do for server in (server1, server2, *other_servers): Instead of for server in [server1, server2] + other_servers
- rectangletangle 11y ago
  I've been wanting this feature for a while as a clean way to combine the results from several queries into a composite object. def combined(*dicts): return {k: v for dict_ in dicts for k, v in dict_.items()} dicts = [({'a': 'a', 'b': 'b'}, {'b': 'bb'}),] assert [{'a': 'a', 'b': 'bb'}] == [combined(a, b) for a, b in dicts]
- Too 11y ago
  Can't tell if you are sarcastic or not but to me the second line is much more readable.
  - agumonkey 11y ago
    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).
  - klibertp 11y ago
    No, both lines are equally readable. A number of operations, placement of operators, names are all the same. The only difference is replacing "," with "]+", which is not any different for your eye* to read. What you mistake for readability is familiarity: after you read a word you need to associate a meaning with it. It takes longer to interpret the meaning of things you didn't see before while grabbing a meaning from a cache is nearly instantaneous. You understood this difference in comprehension speed as a readability difference. My main point is that it makes no sense to talk about readability without first getting used to the grammar and vocabulary of a language. In this case, it's unfamiliar feature in an otherwise normal environment, but it gets worse. There are people who believe they can judge the readability of entirely alien (to them) languages and it hurts those languages reputation pretty badly. Lisps are the prime example of this.
jacobolus 11y ago
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/thread.html#21872 https://mail.python.org/pipermail/python-ideas/2013-July/thr... https://mail.python.org/pipermail/python-ideas/2015-January/thread.html#31012 https://mail.python.org/pipermail/python-ideas/2015-January/... https://mail.python.org/pipermail/python-dev/2015-January/thread.html#137814 https://mail.python.org/pipermail/python-dev/2015-January/th... https://mail.python.org/pipermail/python-dev/2015-February/thread.html#138564 https://mail.python.org/pipermail/python-dev/2015-February/t...
- notatoad 11y ago
  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.
mraison 11y ago
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.
allendoerfer 11y ago
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.

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 11y ago
I wonder why set operations were never supported for dictionaries. a = b | c makes perfect sense, vs: a = b.copy() a.update(c)
- JoshTriplett 11y ago
  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 11y ago
    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 11y ago
      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.
asgard1024 11y ago
Many years ago, I complained to myself that in Python something required two expressions instead of one. Later I understood - it is probably intentional. I think there a design guideline for Python that says roughly if you can create an operator/function with a combination of 2 or 3 operators, then it probably is not worth adding. This keeps standard library relatively small and easy to memorize. Many other language keep adding various flavors of operators (and types, too) despite the fact you can easily build one from another.
- klibertp 11y ago
  Many languages disagree on that rule (2 or 3 operators not worth factoring). Or rather, there are very many different approaches to this problem in various languages. Take a look at Forth, APL, J and possibly Factor to see something radically different than anything you've ever seen (and yes, people do use these). Personally I find well-chosen names to help readability and may help avoid code duplication. There are 2 or 3 operator long things very much worth naming (see for example https://gist.github.com/piotrklibert/a0849f26523cad3d594e#file-refactoring-py-L44 https://gist.github.com/piotrklibert/a0849f26523cad3d594e#fi...). It's a style I call "modern literate," which tries to emulate "literate programming" without extra-language tools. Jeremy Ashkenas uses it in his works, most notably Underscore.js and Backbone.js: the code is simultaneously a manual and a tutorial. See: http://backbonejs.org/docs/backbone.html http://backbonejs.org/docs/backbone.html
  - asgard1024 11y ago
    I am aware of that, that's why I mention it (and I would add Perl and many Lisp-like languages to your list). I appreciate the path that Python took, though, because it keeps language small and orthogonal. There is lot of value in this approach, especially if you share code with someone outside of the project. > There are 2 or 3 operator long things very much worth naming I don't understand your example. But I am talking about functions that are part of the libraries (especially standard ones). How you refactor your code is a different matter.

Redoubts 11y ago

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

geofft 11y ago
That's the point, of course. (Not that I agree.)
pekk 11y ago
If you were happy with 2.5 a few years ago, why is it any more unbearable to use 2.7 today?
- Redoubts 11y ago
  >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 11y ago
    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 11y ago
      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.
saurik 11y ago
We should backport all the good features from 3.x to 2.7: I bet it would only take a few days.

mikelward 11y ago

Finally! I've long wanted to do for server in (server1, server2, *other_servers): Instead of for server in [server1, server2] + other_servers

rectangletangle 11y ago
I've been wanting this feature for a while as a clean way to combine the results from several queries into a composite object. def combined(*dicts): return {k: v for dict_ in dicts for k, v in dict_.items()} dicts = [({'a': 'a', 'b': 'b'}, {'b': 'bb'}),] assert [{'a': 'a', 'b': 'bb'}] == [combined(a, b) for a, b in dicts]
Too 11y ago
Can't tell if you are sarcastic or not but to me the second line is much more readable.
- agumonkey 11y ago
  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).
- klibertp 11y ago
  No, both lines are equally readable. A number of operations, placement of operators, names are all the same. The only difference is replacing "," with "]+", which is not any different for your eye* to read. What you mistake for readability is familiarity: after you read a word you need to associate a meaning with it. It takes longer to interpret the meaning of things you didn't see before while grabbing a meaning from a cache is nearly instantaneous. You understood this difference in comprehension speed as a readability difference. My main point is that it makes no sense to talk about readability without first getting used to the grammar and vocabulary of a language. In this case, it's unfamiliar feature in an otherwise normal environment, but it gets worse. There are people who believe they can judge the readability of entirely alien (to them) languages and it hurts those languages reputation pretty badly. Lisps are the prime example of this.

jacobolus 11y ago

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/thread.html#21872 https://mail.python.org/pipermail/python-ideas/2013-July/thr... https://mail.python.org/pipermail/python-ideas/2015-January/thread.html#31012 https://mail.python.org/pipermail/python-ideas/2015-January/... https://mail.python.org/pipermail/python-dev/2015-January/thread.html#137814 https://mail.python.org/pipermail/python-dev/2015-January/th... https://mail.python.org/pipermail/python-dev/2015-February/thread.html#138564 https://mail.python.org/pipermail/python-dev/2015-February/t...

notatoad 11y ago
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.

mraison 11y ago

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.

allendoerfer 11y ago

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.