3 ms·

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://stackove

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.

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.