On Thu, May 21, 2020 at 12:27 AM James Lu <jam...@gmail.com> wrote:
> > This is already valid in 3.8, so we should forget about overloading :=
> > with a second meaning.
>
> def func(x=(a:=expression), y=a+1):
> def func(x:=options):
>
> These two syntaxes do not conflict with each other.
>
Technically no, but there is potential to confuse beginners.
What about:
def func(x=:options):
or a more realistic example:
def func(options=:{}):
It still looks like `func(x=<default>)` but the `<default>` starts with a
modifier `:` to say 'this is evaluated each time'. `:<expression>` can
loosely be thought of as a shorthand for `lambda: <expression>` where said
lambda function is called each time the def function is called, although it
probably wouldn't actually work that way.
One problem is that this conflicts with some other possible syntaxes that
some people might want. For example I think `:<expression>` has already
been proposed precisely as a shorthand for `lambda: <expression>` in
general. Some might also want `:name` to mean some kind of keyword object
like in Clojure.
Personally I think the best way forward on this would be to accept PEP 505.
It wouldn't solve this particular problem in the most concise way but it
would be pretty good and would be more broadly useful. I see the PEP is
'deferred' - what does that mean exactly? What possible paths are there to
acceptance? Is the rationale for deferral documented anywhere? Are people
supposed to just read all the old discussion(s) and add more posts?
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ATRNUULVRPGRWREBYDQ4WOTKHI252GU7/
Code of Conduct: http://python.org/psf/codeofconduct/
