On Mon, May 31, 2021 at 11:41 PM Steven D'Aprano <steve@pearwood.info> wrote:
It's pretty standard behaviour for Python. Right now, `eval(repr(...))` works unless you have shadowed the name Ellipsis.
>>> err = ValueError('something went wrong') >>> ValueError = list >>> eval(repr(err)) ['s', 'o', 'm', 'e', 't', 'h', 'i', 'n', 'g', ' ', 'w', 'e', 'n', 't', ' ', 'w', 'r', 'o', 'n', 'g']
Yeah, my surprise was kind of a "thinko." I think I was thinking of the eval() separately from the repr(). But nonetheless, the idempotency question still arises, and I believe is reasonable.
Unless we make the ellipsis object `...` callable. But that doesn't help us if the name Ellipsis has been rebound. Then it will call the rebound object.
Let's change the behavior of the Ellipsis object slightly to have either a .__call__() or .__getitem__() method that returns itself
That was exactly what I suggested. The three dots themselves, which CANNOT be bound to any other object, could be callable or indexable. If you define a class Ellipsis to use that name, it makes no difference to `repr(...) == "...[Ellipsis]"` Note that I am NOT proposing `Ellipsis(...)` as the repr for EXACTLY that reason.
Not every builtin needs a mollyguard to protect against misuse.
I'm not likely to rebind `Ellipsis` so that's not really my concern. Rather, I'm interested in the point André Roberge started the thread with. The repr of '...' should be more self-explanatory to beginners. It's basically co-opting the square brackets or parenthesis to mean something that doesn't really have anything to do with calling or indexing in order to have a repr—in tracebacks specifically, but elsewhere also—that reminds users of the connection between `...` and `Ellipsis`. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.