On 16.04.20 22:28, Alex Hall wrote:
Dominik Vilsmeier wrote:
> I'm not sure if this is doable from the compiler
perspective, but what
> about allowing tuples after `**` unpacking:
>
> requests.post(url, **(data, params))
>
> # similar to
> requests.post(url, data=data, params=params)
+1. I can see the practical utility of the feature, but was
strongly against the
other syntax proposals so far. IMO, the above alternative
does a great job of
using an existing feature, and I think it would be rather
easy to explain how
it works.
If we go in that direction, I'd prefer curly braces
instead so that it's more reminiscient of a dict instead of
a tuple, although technically it will look like a set
literal.
Do you intend this "shortcut" syntax to also work in other contexts?
Because indeed if it looks like a set literal it would be confusing
if it emerges as a dict.
My intended semantics are the same as yours, just with different brackets. Of your proposal I could equally say that it looks like a tuple literal and it would be confusing
if it emerges as a dict.
This looks like someone forgot an iterable after the `*`.
I'm not sure how that can be an issue unless someone is not sure whether the code they're looking at runs without a syntax error.
This resembles **kwargs but using it to unpack keyword arguments it
looks weird: `func(**{**, foo, bar})`.
In that special case the inner ** can be optional, and then it just looks like my variation of your proposal.
Or we can have two similar looking syntaxes:
{**, foo, bar}
func(**, foo, bar)
If you're familiar with one of them then the other should become naturally intuitive. The function call syntax is essentially the earlier proposal in this thread, just with two stars.
{:, foo, bar}
{{ foo, bar }}
This is already valid syntax and attempts to store a set inside
another set.
Your quoting is a bit weird, what about the {:, foo, bar} option?
Your proposal `requests.post(url, **(data, params))` is also valid syntax, and has some support, so I was taking that as precedent. Both are guaranteed to fail at runtime under current semantics.
If at all, I'd prefer something like {:foo, :bar}.
I like that too, but it was originally proposed in the old thread so I'm guessing it's not popular enough.
But anyway this
takes the proposal in a different direction.
I think a productive discussion about this topic necessarily has to at least keep dict literals in mind and consider them as a possible way to achieve the goal.