Hacker News Reader

Comment by fyp | Hacker News Reader

  {**d1, **d2}

is very natural if you also write javascript where their spread operator looks like:

  {...d1, ...d2}

View on HN

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.

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

> I would definitely mention integer division as a massive change in py3 too.

To be fair, you can get that in Python 2 too:

  from __future__ import division

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.

I used to work for a huge SEM business working with keywords in all languages of the world. No-brainer.

Even more natural if you write Ruby, which uses an identical syntax.

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.

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

instead of actually useful features like dict deconstruction

The bigger reasons are discoverability (as noted in the section you linked) and the ever-vague notion of Pythonic-ness.

{d1, d2} is not intuitive to a primarily-Python developer, and looks nothing like typical Python. The dict unpacking operator it uses is almost never seen outside function arguments.

Reply on news.ycombinator.com