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