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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/KCDWSAQDA2TSBSLIQ3FBDVI2MN3OPJVD/
Code of Conduct: http://python.org/psf/codeofconduct/
