Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dictionary union (PEP 584) is merged

github.com

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Dictionary union (PEP 584) is merged

#51

Post by py3001 »

privateSFacct wrote: post #38
beanpup_py wrote: post #26

Earlier quoted context omitted.

No, it adds a new merge (|) and update (|=) operator to avoid using {**d1, **d2} because it apparently looks ugly[1]. [1]: https://www.python.org/dev/peps/pep-0584/#d1-d2

And in doing so creates multiple ways to do the same thing which is SUPER SUPER annoying. There has been a recent effort to add all these new operators that don't actually let you do anything you couldn't but now you can confuse everyone by doing it in other ways.

instead of actually useful features like dict deconstruction

Re: Dictionary union (PEP 584) is merged

#52

Post by mrweasel »

It seems that just using + as the operator was reject because it's: "Too specialised to be used as the default behavior."

What does that mean? It works for lists, obviously lists don't need to worry about duplicated values, but it's kind non-intuitive that + won't work for dicts. It think many people view dicts and lists as the same general type of data structure.

Re: Dictionary union (PEP 584) is merged

#53

Post by anentropic »

fulafel wrote: post #40
kbd wrote: post #37

Earlier quoted context omitted.

The best way to do dictionary union is already symbolic: {**d1, **d2} This provides a clearer symbolic notation for dictionaries analogous to what's already available with sets. FWIW the pep discusses what this would look like as a method vs an operator: https://www.python.org/dev/peps/pep-0584/#use-a-method

The best way for in my view is .union(), the new syntax additions are too cryptic.

we already have `set1 | set2` for set unions

and dict keys are basically a set

Re: Dictionary union (PEP 584) is merged

#54

Post by martopix »

tempay wrote: post #41
TylerE wrote: post #32

Earlier quoted context omitted.

No it isn’t.

One of the issues with Python 3 is that there isn’t really one killer feature, it’s countless little ones. Many believe 3.6 was the first release where they added up to enough of a benefit (though f-strings are a big help for many projects). Regardless it no longer matters, the Python 2 ecosystem is now rotting as packages drop support. Every week I have to make one or two hot fixes somewhere to forcibly pin to an ol…

I would definitely mention integer division as a massive change in py3 too. In my field, the @ multiplication operator is also useful.

Re: Dictionary union (PEP 584) is merged

#55

Post by fulafel »

anentropic wrote: post #53
fulafel wrote: post #40

Earlier quoted context omitted.

The best way for in my view is .union(), the new syntax additions are too cryptic.

we already have `set1 | set2` for set unions and dict keys are basically a set

I think that's cryptic too for most people, intuitive just for people who are conversant in bitwise operations.

Re: Dictionary union (PEP 584) is merged

#57

Post by blackandblue »

Znafon wrote: post #5
seemslegit wrote: post #4

I wouldn't have thought about dict unpacking as a solution either but once suggested it seems satisfactory and I don't see how adding a new operator is more discoverable or natural than just putting this method in a more prominent place in the documentation.

Guido himself said he had forgotten about this trick and since it's syntactic sugar, it does not respect dict subclasses or other mappings.

the easy to forget justification is surprising to me. especially when most modern languages have the concept of unpacking, rest, spread or etc.

making the trick work with other mapping types and making it faster is totally understandable though.

Re: Dictionary union (PEP 584) is merged

#58

Post by uryga »

dahfizz wrote: post #29
uryga wrote: post #13

Earlier quoted context omitted.

actually, only dict(d1, **d2) has that problem. it works fine if you unpack into a dict literal: >>> d1 = {1: 'a'} >>> d2 = {2: 'b'} >>> {**d1, **d2} {1: 'a', 2: 'b'} iirc the pep mostly just says that it's suboptimal because it's syntactically heavy/noisy, non-obvious and can't be overloaded in dict subclasses --- i was curious why the two double-stars behave differently despite syntactic similarity. so i went and c…

This seems pretty straightforward. When doing `dict(d1, d2)` You are calling the dict function, and using the normal syntax for unpacking a dictionary into kwargs. In this case, the name for kwargs must be strings.

yeah, that side of the (in)equation was pretty obvious, i was mostly interested in the `{...}` one. i admit that a bytecode listing probably isn't the best exposition, i just like digging into VM stuff :)

Re: Dictionary union (PEP 584) is merged

#59

Post by anentropic »

fulafel wrote: post #55
anentropic wrote: post #53

Earlier quoted context omitted.

we already have `set1 | set2` for set unions and dict keys are basically a set

I think that's cryptic too for most people, intuitive just for people who are conversant in bitwise operations.

these are standard set operations, not bitwise

Re: Dictionary union (PEP 584) is merged

#60

Post by edudobay »

tempay wrote: post #41
TylerE wrote: post #32

Earlier quoted context omitted.

No it isn’t.

One of the issues with Python 3 is that there isn’t really one killer feature, it’s countless little ones. Many believe 3.6 was the first release where they added up to enough of a benefit (though f-strings are a big help for many projects). Regardless it no longer matters, the Python 2 ecosystem is now rotting as packages drop support. Every week I have to make one or two hot fixes somewhere to forcibly pin to an ol…

For me, proper handling and distinction of Unicode vs. binary data was a game changer. I don't know if that's related to my first language being non-English, but I remember it being really important to me and a strong reason why I made the switch years ago.
Post reply on HN