[Python-ideas] User-defined literals

Chris Angelico rosuav at gmail.com
Wed Jun 3 03:05:09 CEST 2015

On Wed, Jun 3, 2015 at 10:47 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> Similarly, this idea could be extended to handle all literal types, so you can do `{'spam': 1, 'eggs': 2}_o` to create an OrderedDict literal, but I think that's ugly enough to not be worth proposing. (A prefix looks better there... but a prefix doesn't work for numbers or strings. And I'm not sure it's unambiguously parseable even for list/set/dict.) Plus, there's the problem that comprehensions and actual literals are both parsed as displays, but you wouldn't want user-defined comprehensions.
>> I thought there was no such thing as a dict/list/set literal, only
>> display syntax?
> That's what I meant in the last sentence: technically, there's no such thing as a dict literal, just a dict display that isn't a comprehension. I don't think you want user-defined suffixes on comprehensions, and coming up with a principled and simply-implementable way to make them work on literal-type displays but not comprehension-type displays doesn't seem like an easy problem.

Yeah. The significance is that literals get snapshotted into the code
object as constants and simply called up when they're needed, but
displays are executable code:

>>> dis.dis(lambda: "Literal")
  1           0 LOAD_CONST               1 ('Literal')
              3 RETURN_VALUE
>>> dis.dis(lambda: ["List","Display"])
  1           0 LOAD_CONST               1 ('List')
              3 LOAD_CONST               2 ('Display')
              6 BUILD_LIST               2
              9 RETURN_VALUE
>>> dis.dis(lambda: ("Tuple","Literal"))
  1           0 LOAD_CONST               3 (('Tuple', 'Literal'))
              3 RETURN_VALUE

My understanding of "literal" is something which can be processed
entirely at compile time, and retained in the code object, just like
strings are. Once the code's finished being compiled, there's no
record of what type of string literal was used (raw, triple-quoted,
etc), only the type of string object (bytes/unicode). Custom literals
could be the same - come to think of it, it might be nice to have
pathlib.Path literals, represented as p"/home/rosuav" or something. In
any case, they'd be evaluated using only compile-time information, and
would then be saved as constants.

That implies that only immutables should have literal syntaxes. I'm
not sure whether that's significant or not.


More information about the Python-ideas mailing list