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
23  1977 
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.
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
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
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
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
[...]
>>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
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.
>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
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
{:} for empty dict and {} for empty set don't look too much atrocious
to me.
this looks consistent to me
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
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.
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.
"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
"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
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
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 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().
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
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
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.
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 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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Gonçalo Rodrigues |
last post by:
Hi,
Does anyone know if and how I can, from within Python, read the
signatures of builtin methods/functions?
The following fails:
>>> import inspect
>>> inspect.getargspec(list.append)...
|
by: Stephen Ferg |
last post by:
Python has a builtin class for staticmethod. Seems to me that Python
should also have a builtin class for abstractmethod. Something like
this...
#######################################
#...
|
by: barnesc |
last post by:
Hi again,
Since my linear algebra library appears not to serve any practical
need (I found cgkit, and that works better for me), I've gotten bored
and went back to one of my other projects:...
|
by: Don Starr |
last post by:
When applied to a string literal, is the sizeof operator supposed to return the size of the string
(including nul), or the size of a pointer?
For example, assuming a char is 1 byte and a char *...
|
by: al |
last post by:
char s = "This string literal";
or
char *s= "This string literal";
Both define a string literal. Both suppose to be read-only and not to be
modified according to Standard. And both have...
|
by: mjpmsa |
last post by:
Hello,
I've been using the O'Reilly book _Programming ASP.Net_ to learn
ASP.Net, but it frustrates me because all of the examples seem to use
the built in form controls. I write good, standards...
|
by: Anders K. Olsen |
last post by:
Hello group
I'm trying to list the users and groups who has read access to a file.
I use .NET 2.0 and FileInfo.GetAccessControl().GetAccessRules(...) and then
loop through the...
|
by: nejucomo |
last post by:
Hi folks,
Quick Synopsis:
A test script demonstrates a memory leak when I use pythonic extensions
of my builtin types, but if I use the builtin types themselves there is
no memory leak.
...
|
by: Hetal |
last post by:
Hi,
I have been working on creating a dynamic table with controls on a
ASP.NET webpage and i have been using literal controls to do that. The
issue that i am facing is, when i have the Start and...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
