[Python-ideas] User-defined literals

[Chris Kaynor]

On Tue, Jun 2, 2015 at 12:40 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Jun 2, 2015 at 12:03 PM, Andrew Barnert via Python-ideas
> <python-ideas at python.org> wrote:
> > This is a straw-man proposal for user-defined literal suffixes, similar
> to the design in C++.
> >
> > In the thread on decimals, a number of people suggested that they'd like
> to have decimal literals. Nick Coghlan explained why decimal.Decimal
> literals don't make sense in general (primarily, but not solely, because
> they're inherently context-sensitive), so unless we first add a fixed type
> like decimal64, that idea is a non-starter. However, there was some
> interest in either having Swift-style convertible literals or C++-style
> user-defined literals. Either one would allow users who want decimal
> literals for a particular app where it makes sense (because there's a
> single fixed context, and the performance cost of Decimal('1.2') vs. a real
> constant is irrelevant) to add them without too much hassle or hackery.
>
> Are there any use cases besides decimals? Wouldn't it be easier to
> just add, say, a fixed "0d" prefix for decimals?
>
> 0x1001  # hex
> 0b1001  # binary
> 0d1.001 # decimal
>

In terms of other included useful options, you also have fractions.

There could also be benefit of using such a system for cases of numbers
with units, such as having the language understand 23.49MB.

That said, very similar results could be achieved in most cases by merely
using a normal function, without the need for special syntax. Decimal and
Fraction are probably the only two major cases where you will see any
actual benefit, though there may be libraries that may provide other number
formats that could benefit (perhaps a base-3 number?).

> 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.
>
> Also there's the idea floating around of making *all* dicts ordered
> (as PyPy has done), which would be much cleaner if it can be managed,
> so I'm guessing that would have to be tried and fail before any new
> syntax would be added for this use case.


One benefit of the proposal is that it can be readily generalized to all
literal syntax, so custom behaviors for native support of ordered dicts,
trees, ordered sets, multi-sets, counters, and so forth could all be added
via libraries, with little to no additional need for Python to be updated
to support them directly.

All-in-all, I'd be very mixed on such a feature. I can see plenty of cases
where it would provide benefit, however it also adds quite a bit of
complexity to the language, and could easily result in code with nasty
action-at-a-distance issues. If such a feature were implemented, Python
would probably also want to reserve some set of the names for future
language features, similar to how dunder names are reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150602/f846cab9/attachment.html>