Rob Cliffe via Python-ideas writes:
I think you're making my point.
*shrug* You wrote "object", I took you at your word.
You're saying that the object part isn't that hard, but other parts of it are.
For values of "hard" == "non-trivial but mostly bikeshedding". I don't think it will be that much harder to get through than Chris's. And in theory it could be easier: it could be implemented with a new builtin such as "quote_expression" that takes a string, and thus needing no new syntax. I actually don't think that will pass, too clumsy to be of practical use. Although it might fly on the same logic as function annotations did: we add the instance flag that says that "this object is a thunk to be evaluated in the current context" and the code in the interpreter that's needed to use it, and postpone syntax until somebody comes up with a really good proposal. In fact, we could combine this strategy with Steven d'Aprano's proposal for a thunk object, in which case Chris doesn't need syntax himself. I'm sure he won't like that, but it's an idea.
And there seems to be no likelihood of anyone tackling it soon.
There's no way to judge that. David Mertz might post a PEP tomorrow for all you know.
I can't see the point of rejecting something that provides a tangible benefit, now, because some fictitious vapourware *might*, one day, provide another way of doing it.
That's a strawman. The argument is not "Your proposal is good, but not perfect, so we reject it." The basic argument is "Your proposal isn't good enough to deserve syntax for reasons given elsewhere, but if you do this other stuff we would likely support it." Sure, there's some component of "it might interfere with the general facility, or be a small cognitive burden, a warty technical debt, if the general facility is implemented", but that's only a tiny part of why people opposing the proposal oppose it.