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

31–40 of 87 posts

Re: Dictionary union (PEP 584) is merged

#31

Post by CameronNemo »

anonymoushn wrote: post #25
seemslegit wrote: post #6

Earlier quoted context omitted.

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

Note that a | b is already a disaster if you try to use subclasses of set. In python 2.7, iirc it would return a set of a's type but without calling the constructor. In python 3 it seems to return a set (not the type of a or the type of b).

Not sure about the set operator, but this operator is meant to handle subclasses better than the status quo.

Re: Dictionary union (PEP 584) is merged

#32

Post by TylerE »

whalesalad wrote: post #15
fyp wrote: post #8

{**d1, **d2} is very natural if you also write javascript where their spread operator looks like: {...d1, ...d2}

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.

Re: Dictionary union (PEP 584) is merged

#33

Post by mokus »

saagarjha wrote: post #20
ehsankia wrote: post #19

Earlier quoted context omitted.

That ship had long sailed with string formatting anyways.

It sailed long before that.

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

Re: Dictionary union (PEP 584) is merged

#34

Post by kbd »

The PEP has this section:

> The new operators will have the same relationship to the dict.update method as the list concatenate (+) and extend (+=) operators have to list.extend. Note that this is somewhat different from the relationship that |/|= have with set.update; the authors have determined that allowing the in-place operator to accept a wider range of types (as list does) is a more useful design, and that restricting the types of the binary operator's operands (again, as list does) will help avoid silent errors caused by complicated implicit type casting on both sides.

Would someone please explain what they mean with regard to being different from set.update, and what could lead to silent errors?

Re: Dictionary union (PEP 584) is merged

#35

Post by eesmith »

saagarjha wrote: post #20
ehsankia wrote: post #19

Earlier quoted context omitted.

That ship had long sailed with string formatting anyways.

It sailed long before that.

Go back to 1.0 and we still had two ways to write strings ("abc" and 'abc'), and two ways to write not equal ("!=" and "").

The last died with 3.0.

But my point is that the Zen of Python must be seen as a post hoc description overlaid onto whatever the actual Python philosophy is. Aligned, certainly, but at times only roughly aligned.

So I don't see it as having sailed (with string formatting, or other specific even) but never having been there in the first place. More like, sailing in the same waters.

Re: Dictionary union (PEP 584) is merged

#36

Post by fulafel »

The problem with sprinkling operator overloading all over the place in non numerical use is that you as tje reader don't get the context hints provided by method names. I think this change is bad in the overall balance.

Re: Dictionary union (PEP 584) is merged

#37

Post by kbd »

fulafel wrote: post #36

The problem with sprinkling operator overloading all over the place in non numerical use is that you as tje reader don't get the context hints provided by method names. I think this change is bad in the overall balance.

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

Re: Dictionary union (PEP 584) is merged

#38

Post by privateSFacct »

beanpup_py wrote: post #26
devy wrote: post #24

Earlier quoted context omitted.

So PEP 584 is a JavaScript inspired feature request?

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.

Re: Dictionary union (PEP 584) is merged

#39

Post by mdrachuk »

anonymoushn wrote: post #25
seemslegit wrote: post #6

Earlier quoted context omitted.

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

Note that a | b is already a disaster if you try to use subclasses of set. In python 2.7, iirc it would return a set of a's type but without calling the constructor. In python 3 it seems to return a set (not the type of a or the type of b).

Wow, one more point for python 3.

Just override ‘__and__’ in your whatever class to replace default return.

Pretty explicit in my book.

Re: Dictionary union (PEP 584) is merged

#40

Post by fulafel »

kbd wrote: post #37
fulafel wrote: post #36

The problem with sprinkling operator overloading all over the place in non numerical use is that you as tje reader don't get the context hints provided by method names. I think this change is bad in the overall balance.

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.
Post reply on HN