Dict Unpacking in Python

https://github.com/asottile/dict-unpacking-at-home

by _ZeD_ • 1 year ago

146 65 1 year ago

Did not know that such things could be accomplished by registering a new file coding format. Reminds me of https://pypi.org/project/goto-statement/

zahlman2• 1 year ago

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).

almostgotcaught4• 1 year ago

it's working at the source code level rather than the AST level.

this (lexing) is the only use of the codec hack - if you want to manipulate the AST you do not need this and can just to `ast.parse` and then recompile the function.

crabbone2• 1 year ago

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.

Y_Y• 1 year ago

You talking about this?

https://jupyter-notebook.readthedocs.io/en/stable/examples/N...

xg155• 1 year ago

I'd argue "import from notebooks" is still only helpful in the "space bar heating" sense.

I think Notebooks are great for quick, "explorative" sketches of code. They are absolutely terrible for organizing "production" code.

I know it often happens that something starts in a notebook and then sort of morphs into a generic script or full-on application. But I think, this is usually the signal you should refactor, pull out the "grown" parts from the notebooks and organize them into proper Python modules.

If you have parts that are still experimental or explorative, consider importing your new modules into the notebook instead of the other way around.

Source: personal experience

nine_k• 1 year ago

In short, it runs a text preprocessor as the source text decoder (like you would decode from Latin-1 or Shift-JIS to Unicode).

agumonkey2• 1 year ago

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

tkcranny2• 1 year ago

Yeah I had totally forgotten about this. I remember seeing it around a bit in the python 2 days when UTF-8 wasn’t always assumed. The fact a ~macro system can be bolted on using this is impressive, hilarious, and shockingly terrible.

zelphirkalt• 1 year ago

I found dictionary unpacking to be quite useful, when you don't want to mutate things. Code like:

    new_dict = {**old_dict, **update_keys_and_values_dict}

Or even complexer:

    new_dict = {
        **old_dict,
        **{
            key: val
            for key, val in update_keys_and_values_dict
            if key not in some_other_dict
        }
    }

It is quite flexible.

peter422• 1 year ago

I love the union syntax in 3.9+:

  new_dict = old_dict | update_keys_and_values_dict

parpfish2• 1 year ago

Don’t forget the in place variant!

  the_dict |= update_keys_and_values_dict

sco1• 1 year ago

The author also has an accompanying video: https://youtu.be/eqiM0xRmFJg

andy99• 1 year ago

  def u(**kwargs):
    return tuple(kwargs.values())

Am I missing something, is this effectively the same?

*I realize the tuple can be omitted here

Grikbdl• 1 year ago

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

Izkata• 1 year ago

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.

sischoel2• 1 year ago

Or use itemgetter:

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

notpushkin3• 1 year ago

Ohhh, nice. Also, attrgetter (which also supports dotted notation to get nested attrs! Sadly, no dotted notation for itemgetter.)

https://docs.python.org/3/library/operator.html#operator.att...

masklinn5• 1 year ago

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

kristjansson• 1 year ago

While not nearly as fun as the OP, I’d note that this sort of unpacking is very pleasant in the newish PEP636 match case statements:

https://peps.python.org/pep-0636/#matching-builtin-classes

xg155• 1 year ago

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.

thayne• 1 year ago

It allows you to use bound variables/constants as long as the expression includes a dot so you can distinguish it from a capture variable.

Scala allows matching against bound variables but requires it either start with an uppercase letter or be surrounded in backtics in the pattern. I don't know that that would make sense for python, but there could potentially be some special syntax to spicify you want to compare against an existing variable instead of capturing a new variable.

nikisweeting4• 1 year ago

I would donate $500 to the PSF tomorrow if they added this, the lack of it is daily pain

almostgotcaught4• 1 year ago

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).

nikisweeting4• 1 year ago

perfect is enemy of good imo, dict destructuring is so valuable that I'm willing to bend some rules / add some rules to make it possible. can't we just copy whatever JS does?

IshKebab3• 1 year ago

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.

IgorPartola2• 1 year ago

Since when can you use data classes for kwargs? There are plenty of times when you should use a dict even if you know the keys.

porridgeraisin2• 1 year ago

Sure, but destructuring makes sense for both. Just assign the variables without corresponding keys a value of None.

crabbone2• 1 year ago

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

porridgeraisin2• 1 year ago

Destructuring/unpacking and packing add more to the language than whatever crap they stuff into every new python release these days. Let's never forget they _removed_ in its entirety a standard library package, that is the level we are dealing with here...

Not saying it needs to be done with the decoder hack, it should have proper compiler support, but it's basically necessary. It's the best feature in JS hands down.

  >> a, b = 2, 3 # say

  >> d = dict_of(a, b)
  >> d
  {"a": 2, "b": 3}

  >> # somewhere else...
  >> { a, b } = d
  >> a + b
  5

The dict_of() function is already possible at runtime with python `ast` magic, see [1]. That package also has unpack_keys() again made possible with `ast`, but we'd of course want proper language support.

[1] https://github.com/alexmojaki/sorcery

agumonkey2• 1 year ago

Coming from lisp/haskell I always wanted destructuring but after using it quite a lot in ES6/Typescript, I found it's not always as ergonomic and readable as I thought.

qwertox• 1 year ago

This confuses me a bit

  dct = {'a': [1, 2, 3]}
  {'a': [1, *rest]} = dct
  print(rest)  # [2, 3]

Does this mean that i can use?

  dct = {'a': [1, 2, 3]}
  {'b': [4, *rest]} = dct
  print(rest)  # [2, 3]

and more explicit

  dct = {'a': [1, 2, 3]}
  {'_': [_, *rest]} = dct
  print(rest)  # [2, 3]

qexat• 1 year ago

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

masklinn5• 1 year ago

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.

odyssey7• 1 year ago

Python needs a better dictionary. Also, Python needs better names for things than dict.

nikisweeting4• 1 year ago

In the meantime I find myself resorting to these:

- https://pypi.org/project/python-benedict/ - https://docs.pydantic.dev/ - https://github.com/alexmojaki/sorcery

yde_java• 1 year ago

I use the Python package 'sorcery' [0] in all my production services.

It gives dict unpacking but also a shorthand dict creation like this:

    from sorcery import dict_of, unpack_keys
    a, b = unpack_keys({'a': 1, 'b': 42})
    assert a == 1
    assert b == 42
    assert dict_of(a, b) == {'a': 1, 'b': 42}

[0] https://github.com/alexmojaki/sorcery

john-radio• 1 year ago

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

rrishi• 1 year ago

im curios why you think so ?

notpushkin3• 1 year ago

So I see asottile has gone from backporting released features [1] to backporting unreleased ones!

[1] https://pypi.org/p/future-fstrings, mentioned in https://github.com/asottile/dict-unpacking-at-home#please-do...

xg155• 1 year ago

Lame: Submit a PEP, campaign for community support, write a patch, go back and forth with the maintainers, endure weeks and months of bikeshedding, then maybe, eventually have your feature included in the next Python release.

Game: Use the codec hack, immediately publish your feature for all Python versions, then write "please do not use" to be safe.

sametmax• 1 year ago

Anthony is also the maintainer of the deadsnake ppa, if you were searching for reasons to love him more.

mixmastamyk• 1 year ago

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?

ziofill• 1 year ago

The confusing bit to me is that the LHS of this

{greeting, thing} = dct

is a set, which is not ordered, so why would greeting and thing be assigned in the order in which they appear?

xg155• 1 year ago

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

  {thing, greeting} = dct

Should have the exact same result.

frollogaston• 1 year ago

After using JS, Python dicts and objects feel so cumbersome. I don't see why they need to be separate things, and why you can't access a dict like `dict.key`. Destructuring is the icing on the cake. In JS, it even handles the named args use case like

   const foo = ({name, age, email}) => { }

I'm guessing all of this has been proposed in Python before, and rejected in part because at this point it'd create way more confusion than it's worth.

tkcranny2• 1 year ago

I don’t mind the distinction of it as a map container keeping dot properties/methods separate from the keyed values. But yeah the endless string quoting is painful coming back from JS, bare key literals in constructors like JS would be a welcome addition for sure, as would named key unpacking like this whole post is about.

Dict Unpacking in Python

Related Stories