[Python-ideas] User-defined literals

[Paul Moore]

On 4 June 2015 at 14:48, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 4 June 2015 at 23:06, Paul Moore <p.f.moore at gmail.com> wrote:
>> As a straw man how about a new syntax (this won't work as written,
>> because it'll clash with the "<" operator, but the basic idea works):
>>
>>     LITERAL_CALL = PRIMARY "<" <any source character except right
>> angle bracket>* ">"
>
> The main idea I've had for compile time metaprogramming that I figured
> I might be able to persuade Guido not to hate is:
>
>    python_ast, names2cells, unbound_names =
> !(this_is_an_arbitrary_python_expression)

The fundamental difference between this proposal and mine is (I think)
that you're assuming an arbitrary Python expression in there (which is
parsed), whereas I'm proposing an *unparsed* string.

For example, your suggestion of !decimal(1.2) would presumably pass to
the "decimal" function, an AST consisting of a literal float node for
1.2. Which has the same issues as anything else that parses 1.2 before
the decimal constructor gets its hands on it - you've already lost the
original that the people wanting decimal literals need access to. And
I don't think your shell script example works - something like
!sh(echo $PATH) would be a syntax error, surely?

My proposal is specifically about allowing access to the *unevaluated*
source string, to allow the runtime function to take control of the
parsing. We have various functions already that take string
representations and parse them to objects (Decimal, re.compile,
compile...) - all I'm suggesting is a lighter-weight syntax than
("...") for "call with a string value". It's very hard to justify
this, as it doesn't add any new functionality, and it doesn't add that
much brevity. But it seems to me that it *does* add a strong measure
of "doing what people expect" - something that's hard to quantify, but
once you go looking for examples, it's applicable to a *lot* of
longstanding requests. The more I look, the more uses I can think of
(e.g., Windows paths via pathlib - Path<C:\Windows>).

The main issue I see with my proposal (other than "Guido could well
hate it" :-)) is that it has no answer to the fact that you can't
include the closing delimiter in the string - as soon as you try to
work around that, the syntax starts to lose its elegant simplicity
*very* fast. (Raw strings have similar problems - the rules on
backslashes in raw strings are clumsy at best).

Like you, though, I don't have time to work on this, so it's just an
idea if anyone else wants to pick up on it.

Paul