On Aug 26, 2019, at 10:51, Guido van Rossum <[email protected]> wrote:
>
> I'd love to squash this conversation (because I don't think it'll lead
> anywhere) but you've nerd-sniped me a little bit.
Well, you started it by saying it was impossible. :)
>
> In 3.8, foo(a := 42) is in fact valid syntax, meaning the same as foo((a :=
> 42)).
OK, I thought that was illegal. Sorry; then we would indeed need new syntax to
do it.
> You can come up with new syntax in 'def' that make this transparent inside
> the function (e.g. your 'def fun(out := outvar)') but in the caller it will
> require special syntax because the Python compiler can't know the signature
> of the called function (this is not a limitation of the CPython bytecode
> compiler but a feature of the language).
Right; the caller can’t know any more than that it’s calling some callable
expression, so we need explicit syntax on the call side to signal different
behavior. And if spam(a:=42) is not currently illegal, we can’t just abuse
that. So the question is what’s the closest non-horrible syntax we _could_ use?
No, I take that back. I agree with you that Python doesn’t need this feature,
so the question of the least horrible way to signal it shouldn’t arise in the
first place; apologies for dragging you into that question anyway, and you
should stop reading this message here…
> We could probably come up with vaguely acceptable syntax similar to C, making
> the caller write foo(&a). (We could even make this introduce 'a' as a local
> variable if it wasn't already known.) This would be a runtime type error if
> foo() doesn't have an output parameter in that position.
This is pretty different from what the OP wanted—it makes you think C-style
explicit pointers for pass by reference instead of C#-style out params, and
that raises expectations that may not be warranted (like if you assign to the
out param before raising, you’d expect the caller to be able to see that
assignment).
On the other hand, it does allow positional rather than just (pseudo-)keyword
arguments to out params, which… I have no idea if that’s a benefit or not, to
be honest, but it might be.
It also conceivably allows for in-our params: if a had a value, then outvar
starts with that value instead of starting unbound. Again, I have no idea if
that’s a benefit or just a further source of confusion.
Another option would be syntax that just treats out params as a whole different
thing from regular params on the call side, say:
spam()->(a:=out)
Is there any context where a call followed by -> is valid today?
(And maybe you could even something similar on the def side, although fitting
the “return params” in with the type of the normal return might be tricky.)
On the plus side, this is ugly enough that hopefully nobody will ever ask for
it. :)
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/KMWUG2GRP5GM3IAWONBMBQBNF665MLSU/
Code of Conduct: http://python.org/psf/codeofconduct/
