PEP218: Representing the empty set

[Andrew McLean]

Looking at PEP218 there is a discussion about the most appropriate way
of representing the empty set. The two alternatives proposed are {} and
{-}. I was wondering why either of these is needed. Why not just use
set()?. It is only two more characters than {-} and a bit more explicit.

Similarly, I find myself initialising dictionaries with dict() rather
than {}.

Am I missing something?

 

[Peter Hansen]

Looking at PEP218 there is a discussion about the most appropriate way
of representing the empty set. The two alternatives proposed are {} and
{-}. I was wondering why either of these is needed. Why not just use
set()?. It is only two more characters than {-} and a bit more explicit.

Similarly, I find myself initialising dictionaries with dict() rather
than {}.

Am I missing something?

Maybe it's nothing more than this distinction: dict() is a call which
*returns* an empty dictionary. {} *is* an empty dictionary. Likewise,
set() returns an empty set, which presumably {-} directly *is* an empty
set.

As someone not involved in the participation, I don't know how much
value my observation has, but to me it looks like a question of readability.
The direct representation flows better than the function call/constructor
approach...

-Peter

 

[Paul Rubin]

Maybe it's nothing more than this distinction: dict() is a call which
*returns* an empty dictionary. {} *is* an empty dictionary.

I don't understand in what ways these are really distinct.

a = []
for i in range(2):
a.append({})
print (a[0] is a[1])

prints 0, if that helps. Clearly "a = {}" and "a = dict()" both run
some code that creates a new empty dictionary. It's not the case that
"a = {}" sets a to an empty dict created at compile time or anything
like that.

 

[John Roth]

Looking at PEP218 there is a discussion about the most appropriate way
of representing the empty set. The two alternatives proposed are {} and
{-}. I was wondering why either of these is needed. Why not just use
set()?. It is only two more characters than {-} and a bit more explicit.

Similarly, I find myself initialising dictionaries with dict() rather
than {}.

Am I missing something?

A very minor oversight. This discussion only makes sense in
the context of having a set literal. The 2.3 set implementation
certainly didn't, and the latest 2.4 development documentation
(Feb 12) also doesn't, so the discussion is moot.

John Roth

 

[Peter Hansen]

Maybe it's nothing more than this distinction: dict() is a call which
*returns* an empty dictionary. {} *is* an empty dictionary.

I don't understand in what ways these are really distinct.

a = []
for i in range(2):
a.append({})
print (a[0] is a[1])

prints 0, if that helps. Clearly "a = {}" and "a = dict()" both run
some code that creates a new empty dictionary. It's not the case that
"a = {}" sets a to an empty dict created at compile time or anything
like that.

I agree. In that example, either is equally readable.

I think the example I would have in mind is a comparison:

if a == []:
# do something
if b != {}:
a.append(b)

or whatever.

I think the difference lies in ones intent. If the empty item is
going to be kept around and used, then a constructor approach seems
appropriate, maybe even arguably more readable. If the empty item
is merely a temporary, to be used and discarded, then the apparent
extra overhead of the call, and the less succinct syntax, lead me to
think the short form is preferable.

-Peter

 

[Paul Rubin]

I think the example I would have in mind is a comparison:

if a == []:
# do something
if b != {}:
a.append(b)

or whatever.... If the empty item
is merely a temporary, to be used and discarded, then the apparent
extra overhead of the call, and the less succinct syntax, lead me to
think the short form is preferable.

But you suffer the overhead either way. The {} syntax may be worse
than the function call syntax because it looks like it avoids the
overhead when it really doesn't. The correct way to avoid the
overhead is with "if len(b) != 0: ... ".

 

[Peter Hansen]

I think the example I would have in mind is a comparison:

if a == []:
# do something
if b != {}:
a.append(b)

or whatever.... If the empty item
is merely a temporary, to be used and discarded, then the apparent
extra overhead of the call, and the less succinct syntax, lead me to
think the short form is preferable.

But you suffer the overhead either way. The {} syntax may be worse
than the function call syntax because it looks like it avoids the
overhead when it really doesn't. The correct way to avoid the
overhead is with "if len(b) != 0: ... ".

Who said this was about overhead? Oh, wait, you thought I did...
because of the part where I said "overhead".

I didn't mean that what is important is whether or not there *is*
actual overhead. Merely that the one approach, with the literal,
fits more easily in the brain and "feels" better. Whether this is
because one (mistakingly) believes at some low level that it has
less overhead or not is irrelevant.

Given the option, perhaps even if it had *higher* overhead, I would
still prefer the more readable (to me) literal form.

-Peter

 

[Tim Roberts]

But you suffer the overhead either way. The {} syntax may be worse
than the function call syntax because it looks like it avoids the
overhead when it really doesn't. The correct way to avoid the
overhead is with "if len(b) != 0: ... ".

Or, the way I would write it:

if b: