On Sun, Feb 3, 2013 at 1:09 PM, MRAB python@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@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.