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 topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/DYH5LZ3Z6CPYDO7CR5OZRQXSSAE7VDD3/
Code of Conduct:http://python.org/psf/codeofconduct/
_______________________________________________
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/V5DSQHL75Y4UMVL33K67EB5AVHZ3ICQR/
Code of Conduct: http://python.org/psf/codeofconduct/
