ways to declare empty set variable

[Sun]

Maybe this is a very primative question, but I just get a bit confused about
'set' and 'Set' module in python.

I understand 'set' is a build in type in python after 2.4(or 2.3) and Set a
seperate module, anyhow, I gonna use build in 'set'.

then the question is how can I declare a empty set variable as a 'var= []'
do to a list variable?

[Marc 'BlackJack' Rintsch]

On Tue, 12 Feb 2008 14:45:43 +0100, Sun wrote:

then the question is how can I declare a empty set variable as a 'var= []'
do to a list variable?

You don't declare variables in Python. Just create an instance of `set`
and bind it to a name:

var = set()

Ciao,
Marc 'BlackJack' Rintsch

[Chris]

On Feb 12, 3:45 pm, "Sun" <[e-mail]:

Maybe this is a very primative question, but I just get a bit confused about
'set' and 'Set' module in python.

I understand 'set' is a build in type in python after 2.4(or 2.3) and Set a
seperate module, anyhow, I gonna use build in 'set'.

then the question is how can I declare a empty set variable as a 'var= []'
do to a list variable?

>>test = set()
test

set([])

>>type(test)

<type 'set'>

You looking for that ?

[Sun]

"Chris" <cw****@gmail.comwrote in message
news:f3**********************************@y5g2000h sf.googlegroups.com...

On Feb 12, 3:45 pm, "Sun" <[e-mail]:

>Maybe this is a very primative question, but I just get a bit confused
about
'set' and 'Set' module in python.

I understand 'set' is a build in type in python after 2.4(or 2.3) and Set
a
seperate module, anyhow, I gonna use build in 'set'.

then the question is how can I declare a empty set variable as a 'var=
[]'
do to a list variable?

>>>test = set()
test

set([])

>>>type(test)

<type 'set'>

You looking for that ?

yeah, that 's what I am looking for, thanks all for such prompt answers!

I was wondering why can't I use a format as "var = {} " to "var=list()" in
set variable, and decided not to bother with it.

Thanks.

[Paul Rubin]

"Sun" <[e-mail]:

I was wondering why can't I use a format as "var = {} " to "var=list()" in
set variable, and decided not to bother with it.

In 3.0 you may be able to say {,} but there is a contingent that would
just as soon get rid of all that special syntax, so you'd say list()
instead of [], dict() instead of {}, etc.

[Gabriel Genellina]

En Tue, 12 Feb 2008 12:04:43 -0200, Sun <[e-mail]ó:

"Chris" <cw****@gmail.comwrote

>>>>test = set()
test

set([])

yeah, that 's what I am looking for, thanks all for such prompt answers!

I was wondering why can't I use a format as "var = {} " to "var=list()"
in
set variable, and decided not to bother with it.

Python 3.0 has set literals {1,2,3} (perhaps they become frozensets
instead). But {} still is, and will be, an empty dict.
In reply to the n-th proposal to define a literal for empty sets, Guido
van Rossum said, in python-ideas:

"All possible proposals have already been discussed at length. Really,
writing set() isn't so bad. Get used to it."

http://mail.python.org/pipermail/pyt...ry/001316.html

--
Gabriel Genellina

[bearophileHUGS]

Paul Rubin:

In 3.0 you may be able to say {,} but there is a contingent that would
just as soon get rid of all that special syntax, so you'd say list()
instead of [], dict() instead of {}, etc.

For Python 3.0 I'd like {} for the empty set and {:} for the empty
dict, but that idea was refused time ago, probably for some mental
backward compatibility. 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).
dict() is a bit more verbose than {}, but it doesn't matter much. With
those dict(), set(), tuple(), list() the only little wart left is the
unary tuple literal: x, that I don't like much, maybe I'd like tuple
to be identified by a pair of delimiters, maybe like [|x|] or
something like that as in the Fortress language. I don't know...

Bye,
bearophile

[Ben Finney]

be************@lycos.com writes:

For Python 3.0 I'd like {} for the empty set and {:} for the empty
dict, but that idea was refused time ago, probably for some mental
backward compatibility.

I agree with not breaking that backward compatibility; it seems
wanton.

Missing that, I think dict() and set() and tuple() and list()

I often use these myself. They're slightly more explicit, which can
help when I want the reader not to have to think too much, and they're
not particularly verbose because the names are well-chosen and short.

look better than using {} for the empty dict and {/} for the empty
set and () for empty tuple

Note that '()' is syntactically null. Parentheses don't declare a
tuple literal, commas do. Parentheses are for grouping within
expressions, not specifying type.

(or {} for the empty dict and set() for the empty set).

I thought you said above that you preferred 'set()' for an empty set?
I'm not sure what it is you're saying now.

the only little wart left is the unary tuple literal: x, that I
don't like much

I agree that it's a wart, but I think the harm done by trying to
change it would be more than the harm done by leaving it in.

--
\ “[W]e are still the first generation of users, and for all that |
`\ we may have invented the net, we still don’t really get it.� |
_o__) —Douglas Adams |
Ben Finney

[bearophileHUGS]

Ben Finney:

I often use these myself. They're slightly more explicit, which can
help when I want the reader not to have to think too much, and they're
not particularly verbose because the names are well-chosen and short.

I'd like "list" be called "array" ;-)

Note that '()' is syntactically null. Parentheses don't declare a
tuple literal, commas do.

() is the literal for the empty tuple:

>>t = ()
type(t)

<type 'tuple'>

>>(1, 2)[0:0]

()

>Parentheses are for grouping within expressions, not specifying type.<

I know, but I prefer Fortress in that regard, where each container has
its specific delimiter(s). In Python ( ) denote:
- expression grouping
- they are very often used to denote tuples (despite being necessary
only for the empty one)
- generators (x for x in ...).
The Boo language shows that () aren't that necessary for the
generators.

I thought you said above that you preferred 'set()' for an empty set?
I'm not sure what it is you're saying now.

Your language isn't my first one, and for me sometimes it's not easy
to express complex things :-) I can try again. Here are syntax pairs
(for empty dict && empty set) sorted from the (IMHO) the best one to
the worst one:
{:} && {}
dict() && set()
{} && set()
{} && {/}

I think the harm done by trying to change it would be more
than the harm done by leaving it in.

I agree.

Bye,
bearophile

[Steve Holden]

Ben Finney wrote:
[...]

>
Note that '()' is syntactically null. Parentheses don't declare a
tuple literal, commas do. Parentheses are for grouping within
expressions, not specifying type.

Tell that to the interpreter:

>>type(())

<type 'tuple'>

>>tuple() is ()

True

>>>

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Ben Finney]

Steve Holden <st***@holdenweb.comwrites:

Ben Finney wrote:
[...]

Note that '()' is syntactically null. Parentheses don't declare a
tuple literal, commas do. Parentheses are for grouping within
expressions, not specifying type.

Tell that to the interpreter:

>type(())

<type 'tuple'>

>tuple() is ()

True

>>

Well, knock me down with a kipper.

That makes it even more a violation of principle-of-least-astonishment
that the '(foo)' form doesn't give a one-element tuple literal.

--
\ "If consumers even know there's a DRM, what it is, and how it |
`\ works, we've already failed." —Peter Lee, Disney corporation, |
_o__) 2005 |
Ben Finney

[Ben Finney]

be************@lycos.com writes:

In Python ( ) denote:
- expression grouping
- they are very often used to denote tuples (despite being necessary
only for the empty one)
- generators (x for x in ...).
The Boo language shows that () aren't that necessary for the
generators.

Now, that one I *am* sure of. Generator literals do not require the
parens at all. However, the syntax of where the generator literal
*appears* can make it necessary to explicitly group the expression
using parens.

>>import string
list(char for char in string.digits)

['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']

>>char for char in string.digits

File "<stdin>", line 1
char for char in string.digits
^
SyntaxError: invalid syntax

So, it's not that parens are "used for generator literals". It's that
parens can be used to make grouping explicit where the syntax would
otherwise be ambiguous.

--
\ "If you're a horse, and someone gets on you, and falls off, and |
`\ then gets right back on you, I think you should buck him off |
_o__) right away." -- Jack Handey |
Ben Finney

[bearophileHUGS]

Ben Finney:

Generator literals do not require the
parens at all. However, the syntax of where the generator literal
*appears* can make it necessary to explicitly group the expression
using parens.

Have you taken a look at Boo?
In Python this isn't possible:
s = char for char in string.digits
You need ( ) there, while in Boo they aren't necessary there.

Bye,
bearophile

[cokofreedom]

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

[Ben Finney]

Nick Craig-Wood <ni**@craig-wood.comwrites:

Ben Finney <bi****************@benfinney.id.auwrote:

be************@lycos.com writes:

Missing that, I think dict() and set() and tuple() and list()

I often use these myself. They're slightly more explicit, which can
help when I want the reader not to have to think too much, and they're
not particularly verbose because the names are well-chosen and
short.

You can also do this with the dict() syntax

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

--
\ "My house is made out of balsa wood, so when I want to scare |
`\ the neighborhood kids I lift it over my head and tell them to |
_o__) get out of my yard or I'll throw it at them." -- Steven Wright |
Ben Finney

[Steve Holden]

co*********@gmail.com wrote:

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
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Boris Borcic]

be************@lycos.com wrote:

>
...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]

Boris Borcic wrote:

be************@lycos.com wrote:

>...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
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Boris Borcic]

Steve Holden wrote:

Boris Borcic wrote:

>be************@lycos.com wrote:

>>...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]

Boris Borcic wrote:

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
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Steven D'Aprano]

On Sat, 16 Feb 2008 11:14:10 -0500, Steve Holden wrote:

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*
--
Steven