Dict Unpacking in Python

Looks really cool!

Will this allow combinations of bound and unbound variables?

E.g.:

  def is_on_horizontal_line(point, line_y):
    match point:
      case (x, line_y):
        return f"Yes, with x={x}"
      case _:
        return "No"

Seems both useful and potentially confusing.

This one is arguably even more of a hack; it's working at the source code level rather than the AST level.

The "coding" here is a bytes-to-text encoding. The Python lexer expects to see character data; you get to insert arbitrary code to convert the bytes to characters (or just use existing schemes the implement standards like UTF-8).

I think there's a package to treat Jupyter notebooks as source code (so you can import them as modules).

While the OP package is obviously a joke, the one with notebooks is kind of useful. And, of course, obligatory quote about how languages that don't have meta-programming at the design level will reinvent it, but poorly.

I love the union syntax in 3.9+:

  new_dict = old_dict | update_keys_and_values_dict

That seems a bit crazy and like it would lead to unpredictable and hard-to-mantain code. (pardon my candor).

yeah that's the funny part here, would never have thought of this

Believe he’s the same person who won’t allow pyflakes to support # noqa, because it’s “opinionated.”

As if dropping that word is some sort of justification. I don’t know what the opinion is! Worse is better?

I don't think they are. They are matched by variable names, so this:

  {thing, greeting} = dct

Should have the exact same result.

> Does this mean that i can use?

They'll both trigger a runtime error, since the key you're using in the pattern (LHS) does not match any key in the dict.

Note that `'_'` is an actual string, and thus key, it's not any sort of wildcard. Using a bare `_` as key yields a syntax error, I assume because it's too ambiguous for the author to want to support it.

None of the last two LHSes will match `dct`, so you'll get a runtime error.

You shouldn't be using dicts for data that you know the name of anyway - use dataclasses or named tuples. Dicts are best for things with keys that are not known at compile time.

you can't do this consistently across all cases without compiler assistance (see https://doc.rust-lang.org/book/ch19-03-pattern-syntax.html or https://peps.python.org/pep-0636/#matching-builtin-classes linked below).

Now come on... for code golf? Why on Earth would anyone want extra syntax in a language with already tons of bloat in the syntax that contribute nothing to language's capabilities? It's, in Bill Gates words, like paying to make airplanes heavier...

This package is a funny gimmick, to illustrate, probably, unintended consequences of some of the aspects of Python's parser. Using this for anything other than another joke is harmful...

You have to pull them out by key name, and not just get everything. Here's a working version, though with a totally different syntax (to avoid having to list the keys twice, once as keys and once as resulting variable names):

  >>> def u(locals, dct, keys):
  ...     for k in keys:
  ...         locals[k] = dct[k]
  ... 
  >>> dct = {'greeting': 'hello', 'thing': 'world', 'farewell': 'bye'}
  >>> u(locals(), dct, ['greeting', 'thing'])
  >>> greeting
  'hello'
  >>> thing
  'world'
  >>> farewell
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'farewell' is not defined

Modifying locals() is generally frowned upon, as there's no guarantee it'll work. But it does for this example.

Yours relies on ordering, OP's presumably does not.

Or use itemgetter:

  >>> from operator import itemgetter
  >>> dct = {'greeting': 'hello', 'thing': 'world', 'farewell': 'bye'}
  >>> thing, greeting = itemgetter("thing", "greeting")(dct)
  >>> thing
  'world'
  >>> greeting
  'hello'

TFA looks things up by key, and allows pulling a subset of the dict.