Miikka Salminen

> A place where I found myself wanting something similar is when passing function pointers instead of closures: > > ```rust > // Compiles > [10].into_iter().map(usize::count_ones); > // Does not...

> While it is not spelled out, I suppose unpacking `...expr` to the surrounding which _length is not uniquely determined_ is still allowed when type of `expr` is known, right?...

> So we could use the `@ ..` syntax for unpacking in expressions as well. EDIT: This means `Expression @ ..`, of course. Thanks for the suggestion. Having more alternatives...

> It seems odd to allow use for constructing tuple like structs, but not for anonymous tuples. > > Is there any reason _not_ to support unpacking in tuples? >...

> Here are a few comments on motivation, largely based on my personal experience and feeling instead of facts, but others might agree as well. Some data-driven evidence might be...

> This example does not convince me. My first thought is that the code is clearer if you define a struct to contain `r`, `g`, and `b`. The unpacking feature...

@lolbinarycat, thanks! I'll elaborate on the suggestions you've given in the RFC text. In my view, especially the `unpack` soft keyword idea seems nice, but I don't really hold a...

Thanks, this looks great! One question: Would adding the `__deprecated__` attribute to the Python object (as per [PEP 702](https://peps.python.org/pep-0702/#runtime-behavior)) be out of scope? It's going to be available (implemented [here](https://github.com/python/cpython/pull/104004/files))...

Nice to hear. :) I could actually try implementing a proof-of-concept leveraging Rust's `#[deprecated]` for marking functions, at least, but would likely need some tips to finalize it into a...

> I also think it's a great idea but to me it feels wrong to use `#[deprecated]` for this. I'd prefer if the syntax is `#[pyo3(deprecated)]` (or something else clearly...