[1]: https://pypi.org/p/future-fstrings, mentioned in https://github.com/asottile/dict-unpacking-at-home#please-do...
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).
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.
https://jupyter-notebook.readthedocs.io/en/stable/examples/N...
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}
new_dict = {**old_dict, **update_keys_and_values_dict}
new_dict = {
**old_dict,
**{
key: val
for key, val in update_keys_and_values_dict
if key not in some_other_dict
}
}
new_dict = old_dict | update_keys_and_values_dict the_dict |= update_keys_and_values_dictAnd like += over list.extend, |= over dict.update is very little gain, and restricts legal locations (augmented assignments are statements, method calls are expressions even if they return "nothing")
dct = {'a': [1, 2, 3]}
{'a': [1, *rest]} = dct
print(rest) # [2, 3]
dct = {'a': [1, 2, 3]}
{'b': [4, *rest]} = dct
print(rest) # [2, 3]
dct = {'a': [1, 2, 3]}
{'_': [_, *rest]} = dct
print(rest) # [2, 3]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.
https://medium.com/codex/stop-using-kwargs-as-method-argumen...
http://ivory.idyll.org/blog/on-kwargs.html
Give me another one.
It’s not meant for production use. Quite clearly so: https://github.com/asottile/dict-unpacking-at-home#please-do...
You can't land a language feature that only sometimes works - that's absolutely horrid UX.
> can't we just copy whatever JS does?
I wasn't aware that js does this and I don't know it's implemented. So maybe I should retract my claim about compiler assistance.
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...
def u(**kwargs):
return tuple(kwargs.values())
*I realize the tuple can be omitted here
>>> 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
>>> from operator import itemgetter
>>> dct = {'greeting': 'hello', 'thing': 'world', 'farewell': 'bye'}
>>> thing, greeting = itemgetter("thing", "greeting")(dct)
>>> thing
'world'
>>> greeting
'hello'https://docs.python.org/3/library/operator.html#operator.att...