

Adding Empty Set Literals to Python - philipbjorge
http://philipbjorge.com/2013/03/16/adding-empty-set-literals-to-python/

======
rakha
"I thought {@} would be a good for an empty set because it arguably looks like
the empty set symbol"

I'm just nitpicking but I don't think this is a good justification - If the @
symbol looks like the empty set symbol, then {@} is the set containing the
empty set

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

~~~
mkhattab
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().

~~~
jrockway
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.)

~~~
mkhattab
> 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...](http://doughellmann.com/2012/11/the-performance-impact-of-using-dict-
instead-of-in-cpython-2-7-2.html)

~~~
andreasvc
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.

------
raymondh
Executive summary: If you don't like part of the language, it is really easy
to add your own hack and make it worse ;-)

Really, you should trust the core developers on this one. Empty set literals
are missing from Python for a reason.

~~~
philipbjorge
I just wish someone could find the old discussions...

The main argument I could see against empty set literals was how wrong it felt
adding it to the grammar. Even adding 3 lines of code for the feature, felt
like it was just creating chaos in a zen-like codebase.

~~~
antfarm
[http://mail.python.org/pipermail/python-3000/2007-April/0066...](http://mail.python.org/pipermail/python-3000/2007-April/006620.html)

[http://mail.python.org/pipermail/python-
ideas/2008-January/0...](http://mail.python.org/pipermail/python-
ideas/2008-January/001316.html)

~~~
andrelaszlo
In both of these replies, Guido is referring to older discussions. I'm curious
now.

~~~
antfarm
[http://mail.python.org/pipermail//python-3000/2006-August/00...](http://mail.python.org/pipermail//python-3000/2006-August/002786.html)

[http://mail.python.org/pipermail/python-3000/2006-April/0014...](http://mail.python.org/pipermail/python-3000/2006-April/001400.html)

------
polemic
That ain't orthogonality, _this_ is orthogonality:

    
    
        dict() = {}
        set() = <>
        tuple() = ()
        list() = []
    

(btw, does anyone actually use `<>` as `!=`?)

~~~
Erwin
They finally got rid of <> in Python 3 (together with the `` as being alias
for repr).

~~~
masklinn
And they're not going to add new syntax to Python 2.7 (and the core team has
been empathetic that there would not be a 2.8), so `<>` could easily be
repurposed for "empty set".

Of course `<1, 2, 3, 4>` would then have to be an alternative set literal.

~~~
andreasvc
This would conflict with greater/smaller than operators, which are also used
on sets to express sub/superset relations. If it wouldn't cause trouble in the
formal grammar, then at least in terms of readability.

~~~
masklinn
> This would conflict with greater/smaller than operators, which are also used
> on sets to express sub/superset relations.

Not any more than `[` being used for both literal lists and indexing.

> If it wouldn't cause trouble in the formal grammar, then at least in terms
> of readability.

It wouldn't cause the slightest trouble in the grammar, and I don't think it'd
cause much if any trouble for readability either.

~~~
andreasvc
In terms of readability the angular brackets arguably don't nest well: <<<0,
1>, 2>, 3>.

Also, having braces for sets happens to coincide with mathematical notation.
Angular brackets would be more appropriate for tuples, in this regard--
although the brackets used for tuples in mathematical notation are less acute:
\langle and \rangle in LaTeX.

I think it's pretty unfortunate that for practical purposes we're forced to
make do with what's available in the ASCII character set, which is pretty much
an accident of history. My favorite solution to the OP's problem would be to
use the Unicode empty set symbol. People who for some reason aren't able to
type it could fall back to set(), and in terms of reading it will be
immediately obvious to everyone that the empty set is intended, which doesn't
hold for all the ad-hoc solutions suggested until now.

------
hwiechers
I think it would be best if empty dictionary was {:} and empty set was {}. Of
course, it would be insane to make this change.

------
sciencerobot
Maybe Guido doesn't like it because it looks weird when compared to the rest
of Python's syntax? Still, I think it's cool. Having sets availably without
importing anything is one of the things I love about Python.

set = <> is still available.

~~~
jmmcd
_set = <> is still available_

Did this get misformatted? I don't know what you mean.

~~~
uraza
I believe sciencerobot is saying that "<>" could be used as the empty set
literal.

~~~
jmmcd
Oh I see, thanks. "s=<>" is less ugly than "s={@}" but, obviously, is
inconsistent with "s={1, 2, 3}".

~~~
ekimekim
Then fix that: s = <1,2,3>

I think that's better than using the same brace-type for sets and dicts
anyway, and it can't be as confusing as () == tuple(), (x) == x, (x,) ==
tuple([x]).

------
codesuela
The webfont doesn't load for me because I have Ghostery installed (it blocks
remote tracking scripts) so the page is all blank except for the code snippets
(because Adobe Typekit is blocked). You should consider adding a fallback
font.

~~~
philipbjorge
Thanks and will do!

I just added a 1 second timeout that puts a default font on if the webfont
hasn't loaded. Just tested with ghostery and it should be good to go.

------
vbtemp
> What I learned: It’s not always hard to make interesting changes to large
> projects.

Should be, it's not always hard to make interesting changes _to very well-
designed and well-architected projects_

------
johnsoft
I vaguely recall seeing a mailing list thread where `{-}` was proposed. I
think it was rejected based on parsing ambiguity, i.e. `{-1}` vs `{-}`. (Or
it's possible I might be losing my memory)

~~~
philipbjorge
I originally implemented it that way and had that exact same issue (it's one
of the revisions on github). Similarly, {/} would also be a problem.

~~~
digisign
How about {,} or s{} ?

~~~
philipbjorge
I didn't think to do {,} which I like. s{} looks weird to me, but I couldn't
tell you why.

~~~
digisign
The s{} alternatve is based on the strange r'' or u'' syntax i've gotten used
to.

------
tantalor

        There should be one-- and preferably only one --obvious way to do it.
        Although that way may not be obvious at first unless you're Dutch.

~~~
dechols
Which is more Pythonic?

list() or []

dict() or {}

set() or ????

I would argue that the left is more pythonic and expressive.

~~~
tantalor
Don't forget tuple() and ().

I don't think any are more pythonic. They are all valid python.

------
SilasX
Is it just me, or is it a little ... obsessive to be _this_ annoyed with
having to use `set()` instead of `{@}`?

~~~
npc
What, you've never gone and hacked an interpreter because you were mildly
annoyed by something? I don't think he actually means for it to be used in
production.

