<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Jun 2, 2015, at 12:33, Florian Bruhin <<a href="mailto:me@the-compiler.org">me@the-compiler.org</a>> wrote:</div><div><br></div><blockquote type="cite"><div><span>* Andrew Barnert via Python-ideas <<a href="mailto:python-ideas@python.org">python-ideas@python.org</a>> [2015-06-02 12:03:25 -0700]:</span><br><blockquote type="cite"><span>This is a straw-man proposal for user-defined literal suffixes, similar to the design in C++.</span><br></blockquote><span></span><br><span>I actually had the exact same thing in mind recently, and never</span><br><span>brought it up because it seemed too crazy to me. It seems I'm not the</span><br><span>only one! :D</span><br><span></span><br><blockquote type="cite"><span>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')`.</span><br></blockquote><span></span><br><span>I think a big issue is that it's non-obvious syntactic sugar. You</span><br><span>wouldn't expect 1.2x to actually be a function call, and for newcomers</span><br><span>this might be rather confusing...</span><br></div></blockquote><div><br></div><div>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).</div><br><blockquote type="cite"><span></span><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>That actually was the use-case I had in mind. I think</span><br><span></span><br><span> {'spam': 1, 'eggs': 2}_o</span><br><span></span><br><span>is less ugly (and less error-prone!) than</span><br><span></span><br><span> OrderedDict([('spam', 1), ('eggs': 2)])</span><br></blockquote><br><div>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. :)</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Also, it's immediately apparent that it is some kind of dict.</span></font></blockquote><br></div><div>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.</div></body></html>