Eric V. Smith writes:
> That's why I think we should have a larger concept that just late-bound
> parameters: I think there's a general concept here that can be extended
> beyond parameters.
One advantage of Chris's preferred syntax is that as a default in a
function's parameter list it could do whatever it needs to do there,
while in an executable context, it could return the object, as :=
does. That's a bit inconsistent and quite ugly, I guess, and it might
lead to code like
def foo(x=>[]):
a = bar()
return x
foo(x=>[a])
which I think would be rather confusing. Whether it would be
acceptable is a question of how often it would be used as an
assignment expression rather than as an assignment statement.
I think I've just convinced myself this is a non-starter, but I'll
leave it in as documentation that defining the syntax is a nontrivial
issue.
> later, we'd have two ways to specify late-bound parameters [0].
We might want that anyway. One of the aspects of Chris's proposal is
that late-bound parameters get resolved to objects in a well-specified
(if complicated) order at call time, before entering the function
body. In
foo(x=othermodule.bar())
the compiler cannot know that x's value is a "deferred object" (aside:
how about "autoevaluated expression object", presumably with an
abbreviated form such as "autoeval" for normal use). I don't see how
we can guarantee order of evaluation without syntax for late binding
of parameters. I think the predictability is a potentially valuable
aspect of Chris's proposal that might justify special syntax for
late-bound defaults of formal arguments.[1]
> [0]: Or arguments, I can never remember which is which: someone needs to
> invent a memorable mnemonic device.
C: argv and argc refer to the actual arguments, not the parameter list.
I just use "formal" vs. "actual" to modify "argument".
Footnotes:
[1] I write "potential" not to deprecate it but because I have no
particular use case for late-bound defaults that demands them, rather
than the sentinel idiom. So I have no sense whether this
predictability is a big deal.
_______________________________________________
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/2Y5GOHDLAWWP5D337BWVRISW65M3Q5CW/
Code of Conduct: http://python.org/psf/codeofconduct/
