On 15/06/2022 23:01, Steven D'Aprano wrote:
On Wed, Jun 15, 2022 at 01:58:28PM +0100, Rob Cliffe via Python-ideas wrote:
Please. This has been many times by several people already. No-one is
going to change their mind on this by now. There's no point in
rehashing it and adding noise to the thread.
Rob, there's no rule that only "people who support this PEP" are allowed
to comment. If it is okay for you to say you like this PEP even more now
than previously, it is okay for David to say that his opinion hasn't
changed.
Of course I wasn't saying that some people aren't allowed to comment.
What I was objecting to was the rehashing of old arguments which have
already been done to death. I refrained, at the time, from offering
counter-arguments, because those have been done to death too.
Especially since David even pointed out one potential change
which might lead him to support the PEP, or at least shift to "neutral".
You are quite right Steven, and perhaps I was too hasty, didn't pay
enough attention to David's suggestion, and failed to address it. Well,
let me address it now. I am afraid I can't do so without repeating some
of my old arguments and thus doing exactly what I asked David not to do,
but he has made a suggestion and it merits being answered. Thank you
for contributing to this thread, David.
"I believe a general "deferred computation" mechanism is useful, but
that one limited to the context of function parameters does more harm
than good is scoped narrowly to that single use. I keyword version
might bridge that gap by introducing "later" or "defer" or "delay" in a
narrow context, but not foreclosing its later use more broadly." [DM]
The bar for adding a new hard keyword to Python is very high.
The suggestion is to add a new keyword to a PEP which absolutely doesn't
need it, on the grounds that it **might** (**not** would - we can't know
without a spec) give compatibility with some fictional vapourware which
- for all people keep talking about it - hasn't happened in years, isn't
happening (AFAIK nobody is working on it), doesn't have anything
remotely close to even an outline specification (people disagree as to
what it should do), very likely never will happen, and at best won't
happen for years.
And if it does, what's the **worst** that could happen? We would have
two ways of writing the same thing! Terrible! Well, we already have
that in effect (yes, I know they generate different compiled code):
x = 42
(x := 42)
{}
dict() # similarly for list, tuple
and I expect there are a host of other examples I can't bring to mind at
the moment,
and the sky hasn't fallen.
I'm sorry, but if that's what it takes to make David or anyone else less
opposed to the PEP, it ain't worth it. Not remotely close.
So It could be a soft keyword, you say? OK, AFAICS that could work.
But let me note in passing that if we consider 4 possible syntaxes:
def func(later parm = default): # Number 1
def func(parm later = default): # Number 2
def func(parm = later default): # Number 3
def func(parm = default later): # Number 4
Number 3, which some might find the most attractive, won't work. Consider:
def f(x = later -y):
Is that a late-bound default of -y? Bad luck; it's already legal syntax
for an early-bound default of `later` minus `y`.
AFAICS the others are possible.
If you have some other syntax in mind, David, please specify.
But (and AFAIK this has not been said before) let's think about this
supposed "consistency". Let's suppose we have a bright-and-shiny,
up-and-running delayed evaluation scheme. I imagine (and again, if this
is not what you have in mind, David, please specify) it would allow you
to write something like
x = expression later
which would assign to x some entity, a "deferred evaluation object"
(DEO), probably containing a code object, which would allow the
expression to be evaluated at some future time (and possibly in some
different scope, but let's not go there now). On the principle of least
surprise, one would want "expression later" to be a Python expression,
and to behave as far as possible in the same way in different contexts.
So you could write stuff like
x = y = expression later
someTuple = (expression1 later, expression2 later)
and so on.
(It's not relevant to my point, but I can't imagine wanting syntax like
Number 1 or Number 2 above:
later x = expression # value of expression to be calculated and
assigned to x at some future time
What would these mean, if legal:
later x = y = expression
x = later y = expression
later x = later y = expression
).
But when I use that same syntax *in a function signature*:
def f(x = expression later):
and then call f(), I do **not** (in most cases) want the default value
of x to be a DEO. I want it evaluated NOW, at function call time. So
where is the consistency? There isn't any. It's a myth. Of course, you
could have a rule that 'later' behaved differently when applied to
function parameter defaults, but that would just be adding confusion by
using the same syntax in two different ways. Making two different
things look the same. In short, late-bound defaults and deferred
evaluation are **not** the same thing (nor is one a subset of the other):
Late-bound defaults are meant to be evaluated at function call
time (and in particular, not some way down in the function body when the
parameter gets used).
DEOs are meant to be evaluated ... well, I don't know when, but
presumably there would be a mechanism (possibly implicit) for saying
"please evaluate this now".
And there's readability. Compare these two syntaxes:
def foo(bar=>[], baz=>timenow(), bam=>inc(baz)):
def for(bar=[] later, baz=timenow() later, bam=inc(baz) later):
Not only is the second one longer and repetitious, it adds more
**words**. People are used to distinguishing between words and symbols
and do it easily. In the first example, all the words are parameter
names or part of their default values. Cluttering the signature with
more words makes it harder, visually, to pick out what is what.
Case rests.
Best wishes
Rob Cliffe
_______________________________________________
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/OKOLFRJIQ5X2UWE6IVRN4GBFBZSOKAJ6/
Code of Conduct: http://python.org/psf/codeofconduct/
