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]

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]

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]

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]

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]

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/python-ideas/2008-January/001316.html

 

[Ben Finney]

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 will gain syntax to specify a literal of type 'set'
set([17, 'foo', 12.5])

but this won't allow you to declare an empty set literal, because
that's already easy with 'set()', and '{}' is taken already for an
empty dict literal.

 

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

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.

 

[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)

(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:

regards
Steve

 

[Ben Finney]

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:

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.

 

[Ben Finney]

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.

 

[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

 

[Ben Finney]

Ben Finney:

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.

We seem to be saying the same thing in different ways.

 

[George Sakkis]

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:

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.

The reason being, of course, that in this case '(1+2) * 3' would give
a result several orders of magnitude more astonishing, so it's well
worth the slight inconvenience of one-element tuples.

George

 

[Ben Finney]

The reason being, of course, that in this case '(1+2) * 3' would
give a result several orders of magnitude more astonishing,

Yes, of course.

so it's well worth the slight inconvenience of one-element tuples.

I didn't make it clear, but my expected solution to this is that '()'
should not create an empty tuple (as I was clearly assuming earlier in
this thread). An empty set can still be created with 'set()'.

That way, it becomes clearer that it's the comma separator, not the
parens, that create a tuple literal. With '()' creating an empty tuple
literal, and '(foo, bar)' creating a two-element tuple literal, it
remains that much harder to remember that '(foo)' does *not* create a
tuple.

 

[George Sakkis]

Yes, of course.


I didn't make it clear, but my expected solution to this is that '()'
should not create an empty tuple (as I was clearly assuming earlier in
this thread). An empty set can still be created with 'set()'.

That way, it becomes clearer that it's the comma separator, not the
parens, that create a tuple literal. With '()' creating an empty tuple
literal, and '(foo, bar)' creating a two-element tuple literal, it
remains that much harder to remember that '(foo)' does *not* create a
tuple.

*shrug* I've never been bitten by this. From a purist POV I see your
point but I guess it's one of the things you learn when you first pick
up Python and never have to think again.

George

 

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

 

[Nick Craig-Wood]

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

dict(a = 1, b = 2, c = 3)

which I find a lot more readable than

{ 'a' : 1, 'b' : 2, 'c' : 3 }

In a lot of circumstances.

The syntax isn't so great when you set things which aren't valid
keywords though...

eg

{ (1,2,3) : 'a', (4,5,6) : 'b' }

vs

dict([ ((1,2,3), 'a'), ((4,5,6), 'b') ])