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

41–50 of 87 posts

Re: Dictionary union (PEP 584) is merged

#41

Post by tempay »

TylerE wrote: post #32
whalesalad wrote: post #15

Earlier quoted context omitted.

This is reason enough to upgrade from Python 2.7 if you are still on it. I use this convenience almost daily.

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 old version to fix something.

Re: Dictionary union (PEP 584) is merged

#42

Post by choward »

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.

I agree. Back in the day when I used Ruby, I remember one of the arguments for Python being their belief that there should be one way to do things. Found one reference:

> There should be one-- and preferably only one --obvious way to do it.

https://www.python.org/dev/peps/pep-0020/

Re: Dictionary union (PEP 584) is merged

#44

Post by _-___________-_ »

wodenokoto wrote: post #43

I haven’t read the entire bug tracking thread, but it seems like people were mostly against it, and have been many times in the past. What made decision makers change their mind and accept this change?

Most of the bug tracking thread was just about whether `somedictsubclass() | somedictsubclass()` should be `dict()` or `somedictsubclass()`

The latter (returns `somedictsubclass`) would cause the `|` operator to rely on the `copy()` method from `dict` which would be the only case where an operator relies on a non-double-underscores method. Based on that, two core devs were against it. The core devs prevailed, and the behaviour will be the former (returns `dict`).

Re: Dictionary union (PEP 584) is merged

#45

Post by orf »

ehsankia wrote: post #19
pansa2 wrote: post #3

Earlier quoted context omitted.

> > Dict union will violate the Only One Way koan from the Zen. > There is no such koan. "Only One Way" is a calumny about Python originating long ago from the Perl community.

That ship had long sailed with string formatting anyways.

F-strings are the one obvious way to do string formatting. There may be other ways, for legacy backwards compatibility reasons, but f-strings are the way to do string formatting.

Re: Dictionary union (PEP 584) is merged

#46

Post by orf »

mokus wrote: post #33
saagarjha wrote: post #20

Earlier quoted context omitted.

It sailed long before that.

It sailed with Turing completeness! At least, the popular interpretation of the phrase that ignores the word “obvious” did.

It sailed when they added the for loop - everyone was happy using while loops, things worked and it was simple.

Now there are TWO ways of calling a block of code repeatedly based? How confusing for new users. Python really went downhill since then.

Re: Dictionary union (PEP 584) is merged

#47

Post by orf »

seemslegit wrote: post #6
Znafon wrote: post #5

Earlier quoted context omitted.

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

imo defaultdict(callback,{**a,**b}) is more readable than a | b without knowing that a or b are defaultdicts and having to reason about which default callback will be used

It’s also really expensive. This new operator works with any Mapping type without needing silly hacks.

Re: Dictionary union (PEP 584) is merged

#48

Post by orf »

choward wrote: post #42
fulafel wrote: post #40

Earlier quoted context omitted.

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

I agree. Back in the day when I used Ruby, I remember one of the arguments for Python being their belief that there should be one way to do things. Found one reference: > There should be one-- and preferably only one --obvious way to do it. https://www.python.org/dev/peps/pep-0020/

There should be one _obvious_ way to do things. Not _one_ way to do things.

The operator is better than the dict unpacking-repacking trick, and will become the obvious way to do it.

Re: Dictionary union (PEP 584) is merged

#49

Post by kzrdude »

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.

Python doesn't use formal interfaces. This makes dicts implement unions in a duck typeable way - the operators.

Re: Dictionary union (PEP 584) is merged

#50

Post by kzrdude »

orf wrote: post #45
ehsankia wrote: post #19

Earlier quoted context omitted.

That ship had long sailed with string formatting anyways.

F-strings are the one obvious way to do string formatting. There may be other ways, for legacy backwards compatibility reasons, but f-strings are the way to do string formatting.

I think you are right. Just left a string of legacy (%-formatting) and dead end (.format()) solutions on the way there.
Post reply on HN