Warning: Bear of Very Little Brain talking.

Aren't we in danger of missing the wood for the (deferred-evaluation) trees here?

    Late-bound-arguments defaults are USEFUL. Being able to specify that a default value is a new empty list or a new empty set is USEFUL. Plenty of people have asked on Stack Overflow why it doesn't "work" already. Yes, lots of those people will still ask, but with late bound defaults they can get a completely satisfactory answer.
    Using None or other sentinel to mean "no value was passed" is basically a hack. A kludge. It is MUCH CLEANER to get a default value when no value is passed without resorting to such a hack. Which is fine if the default value is constant (please don't waste your time quibbling with me if I get the technicalities wrong) and can be evaluated early, but needs a late-bound-default if ... well, if it needs to be evaluated late.
    Furthermore, having a late-bound default which refers to preceding parameters such as
        ..., hi:=len(a) ...
is totally clear to anyone who understands function parameter default values (i.e. pretty much anybody who can read or write functions). And again VERY convenient.
As Chris A has already said, the idiom
    if param = None:
        param = [] # or whatever
is VERY frequent. And saving 2 lines of code in a particular scenario may be no great virtue, but when it happens so VERY frequently (with no loss of clarity) it certainly is.

PEP 671, if accepted, will undoubtedly be USEFUL to Python programmers.

As for deferred evaluation objects:
    First, Python already has various ways of doing deferred evaluation:
        Lambdas
        Strings, which can be passed to eval / exec / compile.
        You can write decorator(s) for functions to make them defer their evaluation.
        You can write a class of deferred-evaluation objects.
None of these ways is perfect. Each have their pros and cons. The bottom line, if I understand correctly (maybe I don't) is that there has to be a way of specifying (implicitly or explicitly) when the (deferred) evaluation occurs, and also what the evaluation context is (e.g. for eval, locals and globals must be specified, either explicitly or implicitly).
So maybe it would be nice if Python had its own "proper" deferred-evaluation model.
But it doesn't.
And as far as I know, there isn't a PEP, either completed, or at least well on the way, which proposes such a model. (Perhaps it's a really difficult problem. Perhaps there is not enough interest for someone to have already tried it. Perhaps there are so many ways of doing it, as CHB says below, that it's hard to decide which. I don't know.) If there were, it would be perfectly reasonable to ask how it would interact with PEP 671. But as it's just vapourware, it seems wrong to stall PEP 671 (how long? indefinitely?) because of the POSSIBILITY that it MIGHT turn out to more convenient for some future model (IF that ever happens) if PEP 671 had been implemented in a different way.
[I just saw a post from David Mertz giving an idea, using a "delay" keyword, before I finished composing this email. But that is just a sketch, miles away from a fully-fledged proposal or PEP. And probably just one of very many that have appeared over the years on envelope backs before vanishing into the sunset ...]

Best wishes
Rob Cliffe

On 31/10/2021 02:08, Christopher Barker wrote:

I'm a bit confused as to why folks are making pronouncements about their support for this PEP before it's even finished, but, oh well.

As for what seems like one major issue:

Yes, this is a kind of "deferred" evaluation, but it is not a general purpose one, and that, I think, is the strength of the proposal, it's small and specific, and, most importantly, the scope in which the expression will be evaluated is clear and simple. In contrast, a general deferred object would, to me, be really confusing about what scope it would get evaluated in -- I can't even imagine how I would do that -- how the heck am I supposed to know what names will be available in some function scope I pass this thing into??? Also, this would only allow a single expression, not an arbitrary amount of code -- if we're going to have some sort of "deferred object" -- folks will very soon want more than that, and want full deferred function evaluation. So that really is a whole other kettle of fish, and should be considered entirely separately.

As for inspect -- yes, it would be great for these late-evaluated defaults to have a good representation there, but I can only see that as opening the door to more featureful deferred object, certainly not closing it.

-CHB

--

Christopher Barker, PhD (Chris)

Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/DYH5LZ3Z6CPYDO7CR5OZRQXSSAE7VDD3/
Code of Conduct: http://python.org/psf/codeofconduct/