On 10/30/2021 10:08 PM, 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.
I think it's safe to say people are opposed to the PEP as it current
stands, not in it's final, as yet unseen, shape. But I'm willing to use
other words that "I'm -1 on PEP 671". You can read my opposition as "as
it currently stands, I'm -1 on PEP 671".
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.
And to me and others, what you see as a strength, and seem opposed to
changing, we see as a fatal flaw.
What if the walrus operator could only be used in "for" loops? What if
f-strings were only available in function parameters? What if decorators
could only be used on free-standing functions, but not on object methods?
In all of these cases, what could be a general-purpose tool would have
been restricted to one specific context. That would make the language
more confusing to learn. I feel you're proposing the same sort of thing
with late-bound function argument defaults. And I think it's a mistake.
If these features had been added in their limited form above, would it
be possible to extend them in the future? As they were ultimately
implemented, yes, of course. But it's entirely possible that if we were
proposing the limited version above we could make a design decision that
would prevent them from being more widely used in the future. The most
obvious being the syntax used to specify them, but I think that's not
the only consideration.
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.
And again, this is where we disagree. I think it should be considered in
the full context of places it might be useful. I (and I think others)
are concerned that we'd be painting ourselves into a corner with this
proposal. For example, if the delayed evaluation were available as text
via inspect.Signature, we'd be stuck with supporting that forever, even
if we later added delayed evaluation objects to the language.
I also have other problems with the PEP, not specifically about
restricting the scope of where deferred evaluations are allowed. Most
importantly, that it doesn't add enough expressiveness to the language
to justify its existence as a new feature that everyone would have to
learn. But also things such as: Where do exceptions get caught and
handled (only by the caller)? How would you pass in "just use the
default" from a wrapper function? And others, but even if they were all
addressed except for the restricted nature of the feature, I'd still be
-1 on the PEP.
Eric
_______________________________________________
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/Q36XZVWOXVV232QSNVRJJJNBRXUD2FXT/
Code of Conduct: http://python.org/psf/codeofconduct/
