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 <stephenjturnbull@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