[Python-ideas] frozenset literals

[Nick Coghlan]

On Sun, Feb 3, 2013 at 1:09 PM, MRAB <python at mrabarnett.plus.com> wrote:
> On 2013-02-03 02:18, Steven D'Aprano wrote:
>>
>> On 03/02/13 05:30, MRAB wrote:
>>>
>>> On 2013-02-02 14:28, Antoine Pitrou wrote:
>>>>
>>>> On Sun, 03 Feb 2013 01:20:38 +1100
>>>> Steven D'Aprano <steve at pearwood.info> wrote:
>>>>>
>>>>>
>>>>> Unfortunately the proposal to use f{ ... } for frozen sets cannot work
>>>>> within the constraints of Python's lexer:
>>>>>
>>>>> http://mail.python.org/pipermail/python-3000/2008-January/011838.html
>>>>>
>>>>> Unfortunately we're running out of useful, easy to enter symbols for
>>>>> literals. Until such time (Python4000 perhaps, or more likely Python5000) as
>>>>> we can use a rich set of Unicode literals, I don't think there is any clear
>>>>> way to have a frozenset literal.
>>>>
>>>>
>>>> I'm not sure what the point is. frozensets are too rarely used to
>>>> deserve a literal notation.
>>>>
>>> Does it need a special notation as such?
>>>
>>> Wouldn't an alternative be to support "frozenset(...)" where "..." is
>>> parseable by ast.literal_eval()?
>>>
>>> The same thing could be done with some other built-in classes.
>>
>>
>>
>> I think that having literal_eval support non-literals is a bad, bad idea.
>> Let's just not go there. It will surely end in tears.
>>
> It needn't go beyond a currently-supported literal passed as an
> argument to frozenset, etc, for a very limited number of built-in
> classes. A literal list or a literal set passed to frozenset would be
> treated as a literal frozenset.

This is why we need a PEP or a PyPI module. It's certainly not clear
to me that special casing in ast.literal_eval (or a new
"ast.limited_eval") is a superior solution to s{} and fs{} syntax for
creating the empty set and frozen sets. (And, as Raymond notes, there
are other compile-time benefits in terms of constant-caching when it
comes to dedicated syntax)

On the other hand, a "limited_eval" style solution might be easier to
extend to other builtins like range, reversed and enum, as well as to
container comprehensions and generator expressions. It also has the
virtue of being possible to write as a PyPI module, and made available
for *current* Python versions, rather than only being available in
Python 3.4+.

It's certainly a space worth exploring, even though the best way to
improve the status quo isn't immediately obvious.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia