On Fri, Jun 17, 2022 at 06:32:36AM +0100, Rob Cliffe wrote:
The bar for adding a new hard keyword to Python is very high.
Likewise for new syntax.
The suggestion is to add a new keyword to a PEP which absolutely doesn't need it,
*shrug* The match...case statement didn't "need" keywords either, we could have picked symbols instead if we wanted to look like APL. Remember that keywords have advantages as well as disadvantages. Given the existence of community support for keywords, the PEP should make the case that symbols are better in this case. Even if that's only "a majority prefer symbols".
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.
I think that is broadly accurate. Harsh but fair: nobody has a concrete plan for generalising "defer" keyword would do. It is still vapourware. [...]
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`.
Good catch.
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).
Not necessarily. I don't recall if this has been raised in this thread before, but it is possible to delay the evaluation of the default value until it is actually needed. I believe that this is how Haskell operates pretty much everywhere. (Haskell experts: do I have that correct?) I expect Chris will be annoyed at me raising this, but one way of implementing this would be to introduce a generalised "lazy evaluation" mechanism, similar to what Haskell does, rather than special-casing late-bound defaults. Then late-bound defaults just use the same mechanism, and syntax, as lazily evaluated values anywhere else. I expect that this is the point that David is making: don't introduce syntax for a special case that will be obsolete in (mumble mumble...) releases. David's point would be stronger if he could point to a concrete plan to introduce lazy evaluation in Python. The Zen of Python gives us some hints: Now is better than never. Although never is often better than *right* now. which possibly suggests that the Zen was written by elves: "I hear it is unwise to seek the council of elves, for they will answer with yes and no." Chris may choose to reject this generalised lazy evaluation idea, but if so it needs to go into a Rejected Ideas section. Or he may decide that actually having a generalised lazy evaluation idea is *brilliant* and much nicer than making defaults a special case. (I think that the Zen has something to say about special cases too.) This raises another choice: should lazy defaults be evaluated before entering the body of the function, or at the point where the parameter is used? Which would be more useful? # `defer n=len(items)` def func(items=[], n=>len(items)): items.append("Hello") print(n) func() Printing 1 would require a generalised lazy mechanism, but printing 0 is independent of the mechanism. As it stands, the PEP requires 0. Which would be better or more useful? I guess Chris will say 0 and David will say 1, but I might be wrong about either of them. One way or the other, these are the sorts of questions that the discussion is supposed to work out, and the PEP is supposed to reference. There are well over 600 emails in this thread and the Steering Council should not be expected to read the whole thing, the PEP is supposed to be an honest and fair summary of alternatives and rejected ideas. Chris is welcome to push for a particular proposal. That is the purpose of the PEP process. He is also supposed to give dissenting arguments and alternatives fair airing in the PEP itself, even if only in a Rejected Ideas section. -- Steve