Re: builtin set literal
In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: [...] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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, 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
[EMAIL PROTECTED] 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(). -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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.
[EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
Paul Rubin http://[EMAIL PROTECTED] wrote:
Steven Bethard [EMAIL PROTECTED] writes:
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
Schüle Daniel [EMAIL PROTECTED] wrote:
{:} 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
{:} for empty dict and {} for empty set don't look too much atrocious
to me.
this looks consistent to me
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
Steven Bethard [EMAIL PROTECTED] writes:
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
Paul Rubin http://[EMAIL PROTECTED] writes:
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
faulkner schrieb:
On Feb 14, 11:55 am, Schüle Daniel [EMAIL PROTECTED] 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
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
[...]
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
On Feb 15, 4:12 pm, Schüle Daniel [EMAIL PROTECTED] wrote:
[...]
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
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
--
http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin set literal
On Feb 14, 11:55 am, Schüle Daniel [EMAIL PROTECTED] 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 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. -- http://mail.python.org/mailman/listinfo/python-list
