On Sun, Dec 5, 2021 at 10:38 AM David Mertz, Ph.D. <david.mertz@gmail.com> wrote:
I first discussed the idea of a "generalized deferred object/type" on this list at least two years ago, probably more than three (I haven't looked through archives lately to be sure the dates). The idea got some vague interest, but I was too lazy, or too busy, or whatever, to write an actual PEP or implementation.
I don’t think a full PEP is required at this point, but throughout this discussion, the idea of a deferred object being a better solution to this same problem has been brought up. My sense it that some folks think if we want late-bound defaults, we really should just do deferred objects. But I honestly don’t get it. My idea of a deferred object would be quite different that this, would not be a great replacement for this, and could quite happily co-exist with this idea. Clearly I’m missing something. So I think a paragraph or two explaining what is meant by defers objects, and how they’d be a better way to address late-bound defaults would be very helpful to the conversation. It's fine to criticize my inaction in advancing the more general idea. But
the result of my failing isn't "therefore PEP 671 should be adopted" as you keep claiming.
Of course not— but you (and I honk others) have used the idea of the possibility of some future deferred construct being a reason to reject this idea. So you have some obligation to explain. PEP 671 is very much the same. It does something worthwhile. But it does
vastly less than needed to warrant new syntax and semantics.
I’m personally ambivalent about that at this point, but you can make that case without referring to some possible new feature. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython