469,927 Members | 1,886 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

builtin set literal

Hello,

lst = list((1,2,3))
lst = [1,2,3]

t = tupel((1,2,3))
t = (1,2,3)

s = set((1,2,3))
s = ...

it would be nice feature to have builtin literal for set type
maybe in P3 .. what about?
s = <1,2,3>

Regards, Daniel
Feb 15 '07 #1
23 1845
On Feb 14, 11:55 am, Schüle Daniel <u...@rz.uni-karlsruhe.dewrote:
Hello,

lst = list((1,2,3))
lst = [1,2,3]

t = tupel((1,2,3))
t = (1,2,3)

s = set((1,2,3))
s = ...

it would be nice feature to have builtin literal for set type
maybe in P3 .. what about?
s = <1,2,3>

Regards, Daniel
sets aren't quite that useful or common. just use a list.
and '<' and '>' already have syntactic meanings.
and that would make python look more like C++, which nobody wants.

Feb 15 '07 #2
Schüle Daniel wrote:
Hello,

lst = list((1,2,3))
lst = [1,2,3]

t = tupel((1,2,3))
t = (1,2,3)

s = set((1,2,3))
s = ...

it would be nice feature to have builtin literal for set type
maybe in P3 .. what about?
s = <1,2,3>
In Python 3.0, this looks like::

s = {1,2,3}

More info here:

http://www.python.org/dev/peps/pep-3100/

STeVe
Feb 15 '07 #3
faulkner schrieb:
On Feb 14, 11:55 am, Schüle Daniel <u...@rz.uni-karlsruhe.dewrote:
>Hello,

lst = list((1,2,3))
lst = [1,2,3]

t = tupel((1,2,3))
t = (1,2,3)

s = set((1,2,3))
s = ...

it would be nice feature to have builtin literal for set type
maybe in P3 .. what about?
s = <1,2,3>

Regards, Daniel

sets aren't quite that useful or common. just use a list.
and '<' and '>' already have syntactic meanings.
well, I thought about this
the empty set <has the meaning of != now
as far as I remember is <depricated and will disappear
When they are gone in P3000, <could be reused as empty set.
and that would make python look more like C++, which nobody wants.
I dont think that actually many people fear this.
we have {} for dicts and I doubt anybody mistake them for C++ brakets.

In my previuos post I forgot to mention

d = dict()
d = {}

s = set()
s = <>

why not, on the first sight everybody will see ... here our
algorithmus deals with unique things/objects ... put in a set.

Regards, Daniel
Feb 15 '07 #4
Steven Bethard schrieb:
Schüle Daniel wrote:
>Hello,

lst = list((1,2,3))
lst = [1,2,3]

t = tupel((1,2,3))
t = (1,2,3)

s = set((1,2,3))
s = ...

it would be nice feature to have builtin literal for set type
maybe in P3 .. what about?
s = <1,2,3>

In Python 3.0, this looks like::

s = {1,2,3}
jepp, that looks not bad .. as in a mathe book.
the only disadvantage I see, that one may confuse it with a dict.

Regards, Daniel
Feb 15 '07 #5
Schüle Daniel wrote:
Steven Bethard schrieb:
>Schüle Daniel wrote:
>>it would be nice feature to have builtin literal for set type
maybe in P3 .. what about?
s = <1,2,3>

In Python 3.0, this looks like::

s = {1,2,3}

jepp, that looks not bad .. as in a mathe book.
the only disadvantage I see, that one may confuse it with a dict.
Perhaps with a very cursory inspection. But the lack of any ':'
characters is a pretty quick clue-in.

STeVe
Feb 15 '07 #6
[...]
>>In Python 3.0, this looks like::

s = {1,2,3}

jepp, that looks not bad .. as in a mathe book.
the only disadvantage I see, that one may confuse it with a dict.

Perhaps with a very cursory inspection. But the lack of any ':'
characters is a pretty quick clue-in.
there is one a bigger disadvantage though
{} empty set clashes with empty dict {}
set() still must be used to generate the empty set
or a hack like
s = {None}.clear()

I think something like {-} as the substitution for empty set
will seem bit to perlish for most of us? :)

Regards, Daniel
Feb 16 '07 #7
On Feb 15, 4:12 pm, Schüle Daniel <u...@rz.uni-karlsruhe.dewrote:
[...]
>In Python 3.0, this looks like::
> s = {1,2,3}
jepp, that looks not bad .. as in a mathe book.
the only disadvantage I see, that one may confuse it with a dict.
Perhaps with a very cursory inspection. But the lack of any ':'
characters is a pretty quick clue-in.

there is one a bigger disadvantage though
{} empty set clashes with empty dict {}
set() still must be used to generate the empty set
or a hack like
s = {None}.clear()

I think something like {-} as the substitution for empty set
will seem bit to perlish for most of us? :)
What about "{,}"? For consistency "(,)" and "[,]" might also have to
be permissible, and maybe even "{:}" for an empty dict. Or perhaps not.

Feb 16 '07 #8
>What about "{,}"? For consistency "(,)" and "[,]" might
>also have to be permissible, and maybe even "{:}" for an
empty dict.
The notion of a set literal was rejected in PEP 218,
http://www.python.org/dev/peps/pep-0218/ . One of the reasons for the
rejection was that the small benefit of a literal notion was more than
offset by the attendant need for syntactical atrocities like those
listed above.
Raymond

Feb 16 '07 #9
Raymond Hettinger:
One of the reasons for the
rejection was that the small benefit of a literal notion was more than
offset by the attendant need for syntactical atrocities like those
listed above.
{:} for empty dict and {} for empty set don't look too much atrocious
to me.
Note: the language Fortress, that in graphic modality uses unicode for
its sources, has many collection literals (6 or more, you can see 3 of
them at page 21):
http://research.sun.com/projects/plr...es9Jun2006.pdf

Bye,
bearophile

Feb 16 '07 #10
{:} for empty dict and {} for empty set don't look too much atrocious
to me.
this looks consistent to me
Feb 16 '07 #11
Schüle Daniel wrote:
>{:} for empty dict and {} for empty set don't look too much atrocious
to me.

this looks consistent to me
Yes, a lot of people liked this approach, but it was rejected due to
gratuitous breakage. While Python 3.0 is not afraid to break backwards
compatibility, it tries to do so only when there's a very substantial
advantage. I guess enough people felt that having a shortcut for set()
was less important than keeping the current spelling of dict() the same.

STeVe
Feb 16 '07 #12
Steven Bethard <st************@gmail.comwrites:
Yes, a lot of people liked this approach, but it was rejected due to
gratuitous breakage. While Python 3.0 is not afraid to break backwards
compatibility, it tries to do so only when there's a very substantial
advantage. I guess enough people felt that having a shortcut for set()
was less important than keeping the current spelling of dict() the same.
There's even a sentiment in some pythonistas to get rid of the [] and {}
notations for lists and dicts, using list((1,2,3)) and dict((1,2),(3,4))
for [1,2,3] and {1:2, 3:4} respectively.
Feb 16 '07 #13
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
notations for lists and dicts, using list((1,2,3)) and dict((1,2),(3,4))
for [1,2,3] and {1:2, 3:4} respectively.
Actually that would be dict(((1,2), (3,4))), of course.
Feb 16 '07 #14
"Paul Rubin" <http://ph****@NOSPAM.invalidwrote:
Steven Bethard <st************@gmail.comwrites:
Yes, a lot of people liked this approach, but it was rejected due to
gratuitous breakage. While Python 3.0 is not afraid to break backwards
compatibility, it tries to do so only when there's a very substantial
advantage. I guess enough people felt that having a shortcut for set()
was less important than keeping the current spelling of dict() the same.

There's even a sentiment in some pythonistas to get rid of the [] and {}
notations for lists and dicts, using list((1,2,3)) and dict((1,2),(3,4))
for [1,2,3] and {1:2, 3:4} respectively.
YUK!

Moving in the wrong direction to bracketmania!

If you are going to use only one kind of brackets, use [] - on most keyboards,
you don't have to press the shift key - think of the numberless hours of total
time
saved by this simple reform...

It will also give Python a very distinctive "look" - unlike any other language.

- Hendrik

Feb 17 '07 #15
"Schüle Daniel" <uv**@rz.uni-karlsruhe.dewrote:

>
{:} for empty dict and {} for empty set don't look too much atrocious
to me.

this looks consistent to me
I disagree. What would be consistent would be to follow the pattern,
and use a different set of delimiters.

Python uses () for tuples, [] for lists, {} for dictionaries.
To be consistent, sets need something else, so you can see at a
glance what you are dealing with.

About all that is left is <>, ugly as it is.

The other way is the start of the slippery slide into alphabet soup.

- Hendrik

Feb 17 '07 #16
Paul Rubin wrote:
There's even a sentiment in some pythonistas to get rid of the [] and {}
notations for lists and dicts, using list((1,2,3)) and dict((1,2),(3,4))
for [1,2,3] and {1:2, 3:4} respectively.
Wow. This makes Python twice more LISPy, than <1, 2, 3and {-} make it
C-ish and Perlish.

Frop Python-zen:
Simple is better than complex.
Flat is better than nested.

Sets are good. Sets are fun. Sets are pythonish (the programmer codes
the logical side of a data structure, bothering less 'bout the
technical). I think, they deserve their literal notation.

zefciu
Feb 20 '07 #17
Steven Bethard:
While Python 3.0 is not afraid to break backwards
compatibility, it tries to do so only when there's a very substantial
advantage.
I understand, but this means starting already to put (tiny)
inconsistencies into Python 3.0...

Unrelated: Ruby and Lisp use ? and ! at the end of the function/method
names to denote a predicate or a function that mutates in place (With
them the list.sort() may be called list.sort!() ). Using Python I
usually put an Q at the end of the name for this purpose. Can Py 3.0
support names ending with "?" too?

Bye,
bearophile

Feb 20 '07 #18
be************@lycos.com writes:
Unrelated: Ruby and Lisp use ? and ! at the end of the function/method
names to denote a predicate or a function that mutates in place (With
them the list.sort() may be called list.sort!() ). Using Python I
usually put an Q at the end of the name for this purpose. Can Py 3.0
support names ending with "?" too?
I don't think that's part of the plan. However, Python seems to use
the -ed suffix for the non-mutating versions of these functions, e.g.
sorted(list) instead of the mutating list.sort().
Feb 20 '07 #19

Paul Rubin wrote:
There's even a sentiment in some pythonistas to get rid of the [] and {}
notations for lists and dicts, using list((1,2,3)) and dict((1,2),(3,4))
for [1,2,3] and {1:2, 3:4} respectively.
Well then for consistency they must want tuple((1,2,3)) for (1,2,3).
Oh oh, that must be tuple(tuple((1,2,3))), no wait ...

Alan Isaac
Feb 20 '07 #20
Steven Bethard:
While Python 3.0 is not afraid to break backwards
compatibility, it tries to do so only when there's a very substantial
advantage.
be************@lycos.com wrote:
I understand, but this means starting already to put (tiny)
inconsistencies into Python 3.0...
Well, there's going to be an inconsistency one way or another:

Lists:
[1, 2]
[1]
[]

Dicts:
{1:2, 2:1}
{1:2}
{}

Sets:
{1, 2}
{1}
set()

Note that if we used {} for the empty set and {:} for the empty dict,
then sets would be consistent, but dicts would be inconsistent. And if
you're really worried about consistencies, take a look at the current
state of tuples:

1, 2
1,
()

There's just not an obvious *right* answer here, so it's better to stick
with the backwards compatible version.

STeVe
Feb 20 '07 #21
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
[...] However, Python seems to use the -ed suffix for the
non-mutating versions of these functions, e.g. sorted(list) instead
of the mutating list.sort().
I've found this to be useful in my own Python libraries. For instance, a
graphic object has move(), scale() etc. methods which mutate, and
moved(), scaled() etc. methods which return new instances. It's
English-specific, but still mnemonically useful.
Feb 21 '07 #22
Steven Bethard:
take a look at the current state of tuples:
1, 2
1,
()
That's not a good situation. I presume the situation/syntax of tuples
in Python 2.x can't be improved. But can it be improved for Py 3.0?
Notes:
- I think in Matlab a single element is seen as the same thing as an
array with len = 1.
- I think Ruby solves the problem of the list/tuple with a freezing
function/operator (like I suggested some time ago).

Bye,
bearophile

Feb 21 '07 #23
be************@lycos.com wrote:
Steven Bethard:
>take a look at the current state of tuples:
1, 2
1,
()

That's not a good situation. I presume the situation/syntax of tuples
in Python 2.x can't be improved. But can it be improved for Py 3.0?
I'm not really losing any sleep over the current tuple syntax. ;-) The
empty tuple is so uncommon in my code that the fact that it's spelled
differently just doesn't bother me.

And anyway, if I've learned anything from the Python community over the
years, it's that syntax is best left to Guido. ;-)

STeVe
Feb 21 '07 #24

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Gonçalo Rodrigues | last post: by
1 post views Thread by Stephen Ferg | last post: by
16 posts views Thread by Don Starr | last post: by
7 posts views Thread by al | last post: by
6 posts views Thread by mjpmsa | last post: by
6 posts views Thread by Anders K. Olsen | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.