[Python-ideas] User-defined literals

[Andrew Barnert]

On Jun 2, 2015, at 12:33, Florian Bruhin <me at the-compiler.org> wrote:
> 
> * Andrew Barnert via Python-ideas <python-ideas at python.org> [2015-06-02 12:03:25 -0700]:
>> This is a straw-man proposal for user-defined literal suffixes, similar to the design in C++.
> 
> I actually had the exact same thing in mind recently, and never
> brought it up because it seemed too crazy to me. It seems I'm not the
> only one! :D
> 
>> Any number or string token followed by a name (identifier) token is currently illegal. This would change so that, if there's no whitespace between them, it's legal, and equivalent to a call to a function named `literal_{name}({number-or-string})`. For example, `1.2d` becomes `literal_d('1.2')`, `1.2_dec` becomes `literal_dec('1.2')`, `"1.2"d` also becomes `literal_d('1.2')`.
> 
> I think a big issue is that it's non-obvious syntactic sugar. You
> wouldn't expect 1.2x to actually be a function call, and for newcomers
> this might be rather confusing...

Well, newcomers won't be creating user-defined literals, so they won't have to even know there's a function call (unless whoever wrote the library that supplies them has a bug).

>> 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.
> 
> That actually was the use-case I had in mind. I think
> 
>    {'spam': 1, 'eggs': 2}_o
> 
> is less ugly (and less error-prone!) than
> 
>    OrderedDict([('spam', 1), ('eggs': 2)])

Well, I suppose that's one advantage of the literals being user-defined: you can use _o in your project, and I can not use it. :)

But you still have to deal with the other issue I mentioned if you want to extend it to collection literals: again, they aren't really literals, or even easy to define except as "displays that aren't comprehensions". A quick hack like this is actually pretty easy to write (especially because in a quick hack, who cares whether using it on a comprehension gives the wrong error, or accidentally "works"); a real design and implementation may be harder.

> Also, it's immediately apparent that it is some kind of dict.

That is a good point. Not that it isn't immediately apparent that OrderedDict(…) is some kind of dict as well... But compared to Swift using ArrayLiteralConvertible to define sets or C++ using array-like initializer lists to do the same thing, this is definitely not as bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150602/32268784/attachment.html>