Hacker News Reader

Comment by jrockway | Hacker News Reader

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' }.)

View on HN

I also prefer the dict() function as well as JS object literals but it's too bad there's a performance penalty to using dict().

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 :).

-- [1]: http://doughellmann.com/2012/11/the-performance-impact-of-us...

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.

Reply on news.ycombinator.com