I personally prefer dict() to {} anyway, so I don't really miss the lack of an empty set literal.
Adding a set literal was a slippery slope anyway. Where's my frozenset literal? Where's my namedtuple literal?
(I also don't particularly like the {} syntax for dicts, because there is {'too_much': 'quoting'} which I find rather ugly. I much prefer dict(too_much='quoting') or, even better, Perl's solution: { too_much => 'quoting' }.)
There's a performance penalty to using Python, too. I wouldn't let miniscule detail affect whether or not you like the code you're reading. (By that logic, you should represent sets as {'element': 1} instead of set('element'), because calling the function "set" is slower than making a dictionary object from the special syntax.)
> There's a performance penalty to using Python, too.
I agree, but if it wasn't for the fact that using dict() is six times slower than using literals then it wouldn't make much of a difference arguing code style [1].
> (By that logic, you should represent sets as {'element': 1} instead of set('element'), because calling the function "set" is slower than making a dictionary object from the special syntax.)
Which is why I guess there are now set literals in Python (just not for empty sets :).
You're worrying about a constant slowdown (6x) on a constant operation (constructing a dictionary with a fixed number of items). In terms of computational complexity, that amounts to two times a negligible constant, i.e., nothing.
I think the reason for having set literals is not performance but completeness and prettier syntax.
Adding a set literal was a slippery slope anyway. Where's my frozenset literal? Where's my namedtuple literal?
(I also don't particularly like the {} syntax for dicts, because there is {'too_much': 'quoting'} which I find rather ugly. I much prefer dict(too_much='quoting') or, even better, Perl's solution: { too_much => 'quoting' }.)