
On 15/06/2022 23:01, Steven D'Aprano 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
On Wed, Jun 15, 2022 at 01:58:28PM +0100, Rob Cliffe via Python-ideas wrote: 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