On Feb 2, 2013, at 6:20 AM, Steven D'Aprano <steve@pearwood.info> wrote:

I think Raymond Hettinger's proposal back in 2008:

http://mail.python.org/pipermail/python-3000/2008-January/011798.html

and the following thread is worth reading. Guido even pronounced his agreement:

http://mail.python.org/pipermail/python-3000/2008-January/011814.html

but then changed his mind (as did Raymond). So the status quo remains.

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 l

Wow, that was a nice recap of the historical discussions.
Thank you :-)

FWIW, if a workable frozenset literal were proposed, I would
have no objections.  

Their original use case was be useable 
as elements of other sets (for sets of sets) 
or as dictionary keys  (to implement graph structures).

Later, it became clear that it would be useful for code-optimization
to treat frozensets as constants that are built when a function
is defined, rather than later when it is invoked.

In the future, frozen sets may obtain other desirable properties.
For example, I'm still evaluating whether to store the 
key/hash entries in a dense array and storing only indicies
in a collision table.  For regular sets, the dense array needs
to over-allocate in order to grow efficiently.  In contrast,
a frozenset could free the excess memory and become
very compact (about a third of the current size). 

If that ever comes to fruition, then a frozenset literal would
be nice because of its compactness as compared to regular sets.


Raymond