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."  [My emphasis - RC.]

  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.