On 12/8/2021 2:40 PM, Brendan Barnwell wrote:
On 2021-12-08 09:59, Chris Angelico wrote:
On Thu, Dec 9, 2021 at 4:55 AM Stephen J. Turnbull
<stephenjturnb...@gmail.com> wrote:
But the "good idea" of general deferreds is only marginally relevant
to our -1s. It's those -1s that constitute the main issue for Chris,
since they're a noisy signal that the SC might think as we do.
Please explain to me *exactly* what your arguments against the current
proposal are. At the moment, I am extremely confused as to what people
actually object to, and there's endless mischaracterization and
accusation happening.
Can we actually figure out what people are really saying, and what the
problems with this proposal are?
1. The status quo is fine. Using None or another sentinel and
checking for it in the body has worked for many years and is not that
big a problem. In theory improvement is always possible, but there is
no urgency to change anything until we have a proposal with fewer
downsides. In addition, as discussed in some posts on this list, not
even all cases of None/sentinel defaults will be obviated by this
proposal.
2. Most of the proposed syntaxes make it difficult to visually
distinguish the late and early-bound defaults (because they all look
similar to a plain equals sign which will still mean a regular
early-bound default).
3. Regardless of the syntax, having the potential for def-time and
call-time behavior to be mixed and interleaved in arbitrary ways
within the same function signature is confusing.
4. Currently anything that is a function default is some kind of
Python object that can be inspected, interacted with, and used
independently of the function/argument whose default it is. This
proposal breaks that assumption. In other words I don't want anything
that is "a default" but is not a "default VALUE".
Brandon sums up my objections here, except in #4 I'd make it "... some
kind of Python object that can be _created_, interacted with, and used
independently ...".
Someone asked what the use case for a "deferred object" would be. I hate
that name, but I'll stick with it here for the time being. Had they
existed, I would have found some way to use them for
dataclasses.fields's default_factory parameter. Instead, I had to use a
zero-argument callable with an unfriendly name.
Image a world where you could create a "deferred object" with
back-ticks, and that would remember the context where it was created.
Then you could have:
@dataclasses.dataclass
class A:
a: int = 0
b: list=`[]`
Instead of:
@dataclasses.dataclass
class A:
a: int = 0
b: list=dataclasses.field(default_factory=list)
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/BOHJ63QPVZ2OIXBF6HBWYBYSIFR4B4LT/
Code of Conduct: http://python.org/psf/codeofconduct/
