In functional languages this is called "destructuring assignment".

This article could be a great jumping off point into namedtuple[1], the walrus operator [2] and the Pattern Matching[3] (Python 3.10), which assist into getting back into the symbolic domain from the structural domain, though you will have to come up with names! :)

Remember that namedtuple has the following additional methods

    _make               Class method that makes a new instance from an existing sequence or iterable
    _asdict             Return a new dict which maps field names to their corresponding values
    _replace            Return a new instance of the named tuple replacing specified fields with new values
    _fields             Tuple of strings listing the field names
    _field_defaults     Dictionary mapping field names to default values.

[2] https://peps.python.org/pep-0572/

[3] https://peps.python.org/pep-0636/

Also (but a bit minor, given that Google tells me Python’s named tuples are immutable, so I guess programmers will know that): if I were to read foo._replace(bar=42) I would think that to modify foo.

Because of that, I like scala’s foo.copy(bar=42) more. It makes it clearer that you have to do foo = foo.copy(bar=42) to ‘change’ the value of foo (actually: bind it to a new value).

  MyClass = namedtuple("MyClass", ["make", "asdict", "fields"])
  x = MyClass(make=10, asdict=11, fields=12)
  print(x.asdict)

The core data model of "almost everything is a mutable lookup table" can be easy to work with and reason about at times, but sometimes it's a little too simple, and you end up with these kinds of ad-hoc and inconsistent workarounds even in the standard library.

I thought it's just called pattern matching. Most functional languages don't have assignment and have bindings instead.

This article describing the Python feature of multiple assignment demonstrates only the destructuring assignment (assignment, because it is Python and these variables can be reassigned). There is no control flow tied to this operation, except for the exceptions that can be thrown when the LHS and RHS have incompatible structure.

Clojure is another example of a language with destructuring binding that is not tied to a control flow construct. Clojure functions and `let` bindings can use a destructuring syntax to bind to elements in a data structure. There is no tightly-linked control flow structure that goes along with this binding mechanism. It is my understanding that there are several libraries available that implement pattern matching, but I do not use these.

Most often, when I have seen pattern matching described to an audience with a background in imperative languages, it is compared to a super-powered switch statement. This gives the impression that the important part is the control flow. Languages such as Python and Clojure show that there is inherent value in the destructuring assignment/bind, even out of the context of control flow.

Iterator unpacking:

    first, *middle, last = t

    match t:
        case first, *middle, last:
            ...

However, arguing that one is a special case of the other misses the entire point of structural pattern matching. We would almost never substitute the latter for the former. They mostly live in different worlds because we use them and think about them much differently:

    # Something that would work but they we don't do
    for item in somedict.items():    
        match item:
            case [key, value]:
                 print(key.upper())
                 print(value)
                 print()
            case _:
                 raise RuntimeError('unexpected kind of item')

    # What we actually do
    for key, value in somedict.items(): 
        print(key.upper())
        print(value)
        print()

    - point to a structure / object
    - declare a variable
    - access the object / structure field and assign it to var
    - repeat for every information you want to extract from the struct / object

Unpacking doesn't let you specify default values if cardinality doesn't match, nor can you extract dictionaries by keys.

Since operators.itemgetter and itertools.slice are limited, I end up either adding a dependency or reinventing the wheel for every project.

I'm a bit confused by this one, but maybe I'm misunderstanding. Does this not accomplish what you're defining?

  def parse_record(first=0, second=1, **all_the_others) -> dict:
      return dict(first=first, second=second, **all_the_others)

  dictionary = dict(first=99, third=2)
  parse_record(**dictionary)

  > {"first": 99, "second": 1, "third": 2}

    d = {'a' : 10, 'b' : 20, 'c' : 30}
    {'a' : v1, 'b' : v2, **others} = d
    print(v1, v2, others) # prints 10, 20, {'c' : 30}

The working code in Python, as a function, would be:

    def extract(mapping, *args, **kwargs):
        for a in args:
            yield mapping[a]
        for key, default in kwargs.items():
            yield mapping.get(key, default)

Python really needs something like:

    {foo: "default", mapping} = mapping

    foo = mapping.pop("foo", "default")

Dictionary unpacking compatible with the match/case syntax could look like:

   {"foo": foo, **rest} = mapping 

Also using ? For attributes that might be there and being able to chain that is sooo awesome.

These two things make for example working with nested Json in JS so much better than in Python.

We would need a ? to says "ignore AttributeError, IndexError and KeyError on that access".

However, the use of {} for set is not a problem.

First, remember than Python is much, much older than JS. Insight is 20/20. Second, you could always use a different syntax.

Functional languages that have pattern matching have wildcard matches that allow you to explicitly handle things that don't match as expected and also have tail matching for lists.

> nor can you extract dictionaries by keys

I'm not exactly sure what you mean here, but you can definitely do that for records in F# and maps/structs in Elixir. It's done all the time.

Now you can do:

    import operator
    foo, bar, baz = operator.itemgetter('foo', 'bar', 'baz')(mapping)

  first, second, *others = some_tuple

   first, second, *others = some_tuple

    first, second, *_ = some_tuple

    (lambda (x, y): x+y)((2, 3),)

    lambda (x1, y1), (x2, y2):  return abs(x2 - x1) + abs(y2 - y1)

Not as nice, but:

    (lambda x, y: x+y)(*(2, 3))

  lambda i,(x,y): x[i]+y[j]

But we've got a walrus operator now, because... less lines = more readable?

https://mail.python.org/archives/list/python-dev@python.org/...

The referenced thread isn't Python's finest hour. A: "Hey, this feature is slightly inconvenient to implement in AST, let's kill it." B: "Many users haven't heard of this, so let's kill it." C: "I find it useful and there's not real advantage in killing it". A&B: "Okay, it's gone".

Really, you're better-off just enjoying a language that is mostly nice and mostly well-designed. Don't read the development threads. It will spoil the illusion.

Similar thing about adding animated png support in Firefox, https://bugzilla.mozilla.org/show_bug.cgi?id=257197

Petabytes of bandwidth wasted, and probably gigawatts of electricity.

This like google internal behavior leaking out in the real world. Actively user hostile or at least indifferent.

Observe: me, throwing a fit.

>> Yes, we're using it"

> Okay, it's gone"

[rage]

The one thing I agree with in the thread is the confusion of

  foo = lambda (x,y): x+y
  foo(1,2) #boom

  foo = lambda (x,y),: x+y

  a, = [1]
  b = (1,)
  c = 1,

And if you really want to make the perfect lambda, you can do that with code generation and frame walking/patching.

http://farmdev.com/src/secrets/framehack/index.html

   lambda i, t: t[0][i] + t[1][i]

Also, note that I don't "deride" the walrus operator. But it does smack of inconsistency. Are we aiming for clean notation or not?

You can fight Python on lambda support, or you can build the language you want. It gives you the tools.

I am not arguing about lambda legibility, but tilting at windmills rather than just walking around them. They can't move.

[0] That level of access was essential when I was working on https://codewords.recurse.com/issues/seven/dragon-taming-wit...

I have never had a framehack spontaneously break. Self proclaimed Pythonistas of course make a sour face, like their God was offended, but that isn't a logical argument against.

I really enjoy your compiler art, please keep it up. Are you doing anything with Wasm these days?

I dislike style nazis too, e.g. carping when Peter Norvig's code won't pass PEP 8.

I'm just leery of the expected cost in this kind of case. It can go on working for years until some new complication or some change in the ecosystem makes it suddenly create a really weird problem. Or when you want to try moving to a fancy new Python implementation, you find you have this friction. Matter of judgement where some chance of such messes is paid for by what it can do for you. (Of course when it's less "load bearing" the balance shifts.) With https://coverage.readthedocs.io/en/stable/ for example, it used bytecode hacks to do something you couldn't do otherwise, and that's unlikely to mess you up.

I have had old C programs go crazy years later in a really hard to debug way because newer compilers may interpret your code like your ex-wife's divorce lawyer (as Kragen put it). Back in the day a lot of us thought we had a different kind of relationship with C compilers, and it'd be fine to code to that informal social contract. (Just a loose analogy.)

I'm piddling away at https://github.com/darius/cant these days. (Some of the motivation was feeling too confined by Python, actually.) No Wasm, but I'm happy it exists! I tried to make a system like it 20 years ago (Idel) and gave up too soon.

Chez is a great Scheme, but it doesn't have a Wasm backend. I find https://github.com/schism-lang/schism very interesting.

As for C programs going crazy, well yeah. I did a thing where I would copy of the body of functions around in memory, it worked on some version of Linux and GCC, but only by accident. I would be much less comfortable doing this kind of circuit bending than modifying Python stack frames. If I were to achieve a similar goal in the future, I'd use TCC, generate C code and compile directly into memory.

Framehacks aren't going to do the same thing, and one should have tests for it regardless. Framehacks get you tail calls, stack scope and a bunch of other nice properties.

Happy Hacking!

Introducing side-effects in the middle of expressions with the walrus operator is weird semantics, though admittedly sometimes very convenient.

    if match := re.search(r"Score = (\d+)", data):
        print(match[1])
    else:
        print("Not found")

  first, *rest = xs
  rest = tuple(rest)

Another trick I often use:

  the_only, = xs

Example:

    julia> X = (this = 3, that = 5)
    (this = 3, that = 5)

    julia> this
    ERROR: UndefVarError: this not defined

    julia> (;that, this) = X;

    julia> this
    3

    julia> that
    5

https://stackoverflow.com/a/69860087

    >>> from types import SimpleNamespace
    >>> d = {"one":1, "two":2}
    >>> ns = SimpleNamespace(**d)
    >>> ns.two
    2

However, I almost never use SimpleNamespace in real code. Dicts offer extra capabilities: get, pop, popitem, clear, copy, keys, values, items). Classes/instances offer extra capabilities: unique and shared keys in distinct namespaces, instances knowing their own type, and an elegant transformation of method calls ``a.m(b, c)`` --> ``type(a).m(a, b, c)``. Dataclasses and named tuples have their advantages as well. In practice, it is almost never that case that SimpleNamespace beats one of the alternatives.

https://peps.python.org/pep-0636/

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://github.com/mauro3/Unpack.jl

You can always partially unpack, just only put what you need on the LHS

    # oops, ValueError on `item = "noequals"`
    key, value = item.split("=", 1)

  key, sep, value = item.partition("=")

  key, *value = item.split("=", 1)
  if value:
      value = value[0]
  else:
      value = None

    key, value ?= item.split("=", 1)

(Edit: the semantics of this could be even more generic, like Ruby's `[...] rescue value` syntax for turning any raised exception into a default value instead.)

  value = value[0] if value else None

I’m happy that js and python have also adopted it.

    >>> n = list(range(10))
    >>> n[::3] = 'fizz'
    >>> n
    ['f', 1, 2, 'i', 4, 5, 'z', 7, 8, 'z']
        

    head, *middle, tail = numbers

  x = y = None

   a = b = 10       # multiple assignment

   a, b = b, a      # simultaneous (or parallel) assignment

The language specifies that simple statements can be separated by semicolons. Black eliminates this part of the language, essentially overriding Guido's decision.

The language specifies that four different quoting characters are available. Black eliminates this part of the language, mandating double quotes in code and single quotes in a repr output, essentially overriding Guido's decision.

The language specifies that in-line comments can start anywhere on a line. Black eliminates the writer's option to line-up their comments vertically, essentially overriding Guido's language decision.

The language allows and PEP 8 encourages using whitespace to aid readers in reading mathematical expressions just like sympy and LaTex do: ``3x*2 - 2x +5``. Black eliminates this possibility and mandates equal spacing regardless of operator precedence: ``3 * x * 2 - 2 * x + 5``. Once again, this overrides Guido's judgment.

Wouldn't be better for Guido to decide what the language allows rather than have a downstream tool narrow the range of what is possible?

Pushing extra spaces into slices is another one I don't care for.

https://pypi.org/project/gray/

    for (auto& [key, value] : persons)

anyone know why this works in python

  lst=[]
  lst+=2, # note , in the end
  print(lst) #[2]

   [] + (2,)

   TypeError: can only concatenate list (not "tuple") to list

   L = []
   L += (2,)

In the end, it makes sense because I can't tell you if []+() should be a tuple or a list, and even if I did, I might have a different answer for ()+[]; whereas L+=bla looks like the type of L should not change.

    lst += (2,)

   ()          # Makes a zero-tuple. The parens are required.

   2,          # Makes a one-tuple.
   (2,)        # Makes a one-tuple. The parens are optional.

   [2]         # Makes a list of size one.
   [(2)]       # Also makes a list of size one.
   [2,]        # Also makes a list of size one.

   f(x, y)     # Call a function with two arguments.
   f((x, y))   # Make a 2-tuple and call a function with one argument.

BTW, kind of a tangent, I've always assumed (but not checked) that every "()" literal evaluates to one singleton zero-tuple, do you know if that's true?

Also, it used to be true that ``frozenset() is frozenset()``, but that was lost in the war on singletons and global state.