ways to declare empty set variable

[Ben Finney]

You can also do this with the dict() syntax

As was implied by the plural "these" in "I often use these myself".

 

[Steve Holden]

The irony that, x = (,) produces an error.

Personally I would of thought it would be a better example of an empty
tuple than anything else, but it still isn't that readable.

The use of dict/list/tuple/set seems to stand out a lot better, makes
it readable! Else in a few years you'll have §x§ = !^!()

Or maybe I am going crazy...

Well, to me (,) makes about as much sense as {:}, which is to say none
at all.

The call on the type with an empty argument list is certainly the most
consistent usage, and will extend easily to new types.

regards
Steve

 

[Boris Borcic]

...Missing that, I think dict() and set() and
tuple() and list() look better than using {} for the empty dict and
{/} for the empty set and () for empty tuple (or {} for the empty dict
and set() for the empty set).

The problem I have with them is in no way the looks, it is that they are not
strictly equivalent as they imply dictionary lookups. Which shows in performance, eg

>>> import timeit
>>> timeit.Timer('[]').timeit() 0.22358344426456436
>>> timeit.Timer('list()').timeit() 0.54574505977715049
>>> timeit.Timer('{}').timeit() 0.21328632549668214
>>> timeit.Timer('dict()').timeit()

0.50557906102591232

Cheers, BB

 

[Steve Holden]

...Missing that, I think dict() and set() and
tuple() and list() look better than using {} for the empty dict and
{/} for the empty set and () for empty tuple (or {} for the empty dict
and set() for the empty set).

The problem I have with them is in no way the looks, it is that they are not
strictly equivalent as they imply dictionary lookups. Which shows in performance, eg

import timeit
timeit.Timer('[]').timeit() 0.22358344426456436
timeit.Timer('list()').timeit() 0.54574505977715049
timeit.Timer('{}').timeit() 0.21328632549668214
timeit.Timer('dict()').timeit()

0.50557906102591232

But this is "performance" in the abstract. It's hardly going to matter
if you use it once in the initialization of your program, but if it
occurs deep inside a quadruply-nested loop that is executed 10^12 times
it may have an impact on performance.

Before you have any code is exactly the *wrong* time to be considering
performance.

regards
Steve

 

[Steven D'Aprano]

Before you have any code is exactly the *wrong* time to be considering
performance.

Well, not really.

Don't we already tell people "don't use repeated string concatenation,
because it is slow", even *before* we know whether it is a bottleneck in
their program or not?

The problem occurs when people make "fastest" the *only* consideration,
instead of just one out of many. For instance, {} and dict() are very
different. Consider this:


They not only have different performance, but different semantics. If you
consider it desirable to shadow such built-ins or not is open to debate,
although consider this:
.... set
.... except NameError:
.... from sets import Set as set
....
You can't do that with syntax.

 

[Boris Borcic]

...Missing that, I think dict() and set() and
tuple() and list() look better than using {} for the empty dict and
{/} for the empty set and () for empty tuple (or {} for the empty dict
and set() for the empty set).

The problem I have with them is in no way the looks, it is that they are not
strictly equivalent as they imply dictionary lookups. Which shows in performance, eg

import timeit
timeit.Timer('[]').timeit() 0.22358344426456436

timeit.Timer('list()').timeit() 0.54574505977715049
timeit.Timer('{}').timeit()

0.21328632549668214
timeit.Timer('dict()').timeit()

0.50557906102591232

But this is "performance" in the abstract. It's hardly going to matter
if you use it once in the initialization of your program, but if it
occurs deep inside a quadruply-nested loop that is executed 10^12 times
it may have an impact on performance.

In that case about 2.89 days, to be exact.

And I don't know about you, but when I write tight nested loops, I can't help
opening an eye on not gratuitously wasting time in the innermost loops, well
before I come to the point of measuring performance. And I find the case of []
vs list() (or {} vs dict()) to become a specific nuisance in that context.

Before you have any code is exactly the *wrong* time to be considering
performance.

Yeah right, [] and {} are premature optimizations, one should always use list()
or dict() unless one detains figures to justify the more exotic forms

regards
Steve

Cheers, BB

 

[Steve Holden]

Steve Holden wrote: [...]

Before you have any code is exactly the *wrong* time to be considering
performance.

Yeah right, [] and {} are premature optimizations, one should always use list()
or dict() unless one detains figures to justify the more exotic forms

My natural inclination would be to go for the literal forms where they
are available, but that would be for readability rather than speed. If
just happens to be a double win. It's about four years since I wrote a
program that ran for more than 24 hours.

regards
Steve

 

[Steven D'Aprano]

It's about four years since I wrote a program that ran for more than 24
hours.

Let me guess... and then you discovered ''.join(['x', 'y']) instead of
'x'+'y'?

*wink*