Live data from Hacker News

Dictionary union (PEP 584) is merged

github.com

81–87 of 87 posts

Re: Dictionary union (PEP 584) is merged

#81
Python 2 Community: We are in hell, we have to stop working on everything to upgrade to Python 3, there is no straightforward way to upgrade, many of our python 2 libraries haven't been updated, and there are tons of little bugs that are hard to fix.

Python 3 Community: Look at thing cool dictionary merging thingy!

Re: Dictionary union (PEP 584) is merged

#82
post #62
post #35

Earlier quoted context omitted.

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…

The Tao that can be told is not the eternal Tao

    Can the Tao be found
    where there is no Tao?

Re: Dictionary union (PEP 584) is merged

#83
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

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.

Re: Dictionary union (PEP 584) is merged

#84
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.

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.

It's pretty obvious with the context of other languages, but wildly outside the norm for Python. I rarely see dict unpacking outside function signatures.

Re: Dictionary union (PEP 584) is merged

#85
post #67
post #64

Earlier quoted context omitted.

I disagree. In logging for example, ‘%s’ with the value as an argument to the logger is preferred because the formatting can be ignored if the log level is not sufficient to print.

Log formatting is a different problem than string formatting. With log formatting you pass the formatting arguments as function parameters, which is completely different from any other way you format strings.

I think you're getting downvoted because logging is basically doing:

    def log(fmt, *args):
        print(fmt % args)
Hardly a huge change.

Re: Dictionary union (PEP 584) is merged

#86
post #45

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 F-strings are bad for i18n. It sucks to use them with a database of string localizations because the variable name is now embedded in dozens of translated F-strings and basically becomes immutable.

Re: Dictionary union (PEP 584) is merged

#87

I wish there was a union operator for typing as well to replace `Union[str, int]` with just `[str|int]`.

PEP 604 (draft) proposes this:

  def f(list: List[int | str], param: int | None) -> float | str:
      pass

  f([1, "abc"], None)
https://www.python.org/dev/peps/pep-0604/
Post reply on HN