builtin set literal

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

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

 

[faulkner]

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.

 

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

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

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

 

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

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

 

[Steven Bethard]

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

 

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

[...]

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

 

[Steven Bethard]

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

 

[MRAB]

[...]

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.

 

[Raymond Hettinger]

What about "{,}"? For consistency "(,)" and "[,]" might
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

 

[=?ISO-8859-1?Q?Sch=FCle_Daniel?=]

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

this looks consistent to me

 

[bearophileHUGS]

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/plrg/PLDITutorialSlides9Jun2006.pdf

Bye,
bearophile

 

[Steven Bethard]

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

 

[Paul Rubin]

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.

 

[Paul Rubin]

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.

 

[Hendrik van Rooyen]

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

 

[Hendrik van Rooyen]

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

 

[zefciu]

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, 3> and {-} 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

 

[bearophileHUGS]

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

 

[Paul Rubin]

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

 

[Alan Isaac]

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