very Very VERY dumb Question About The new Set( ) 's
Raymond Arthur St. Marie II of III
Please be kind and read this like you know I've been up 33-34 hours reading
PEP's but...
Doc\ref 2.6 Delimiters show's three unused characters "@ $ ?".
@ sort of looks like and sort of sounds like a set an
$ well sort of obvious.
I can imagine that the $ would be confused for money and @ is ugly.
You folks have prob'ly been all over this.
Even thou I've been using Python since 1.4, I only joined the comp.lang.python
a couple weeks ago so I don't know the flame wars over the Set implimentation.
Ray St. Marie --- Afraid to sign his name to this one
Ras...@aol.bomB
John Roth
"Raymond Arthur St. Marie II of III " <ras...@aol.commorespam> wrote in
message news:20030723144732...@mb-m10.aol.com...
Is your question why they didn't add new operators for the set
operators, rather than overloading the existing ones?
There are two factors. One is that Guido is holding those three
characters back for some time when we *really* need them. Sets
are still somewhat experimental - if they take off like wildfire they
may migrate into the core. Adding operator symbols for something
that's in a library doesn't seem like a real good idea.
The other issue is that those three characters have no particular
relationship to sets, while the Unicode standard contains the
actual set operator symbols used in mathematics. When the source
script finally becomes Unicode will be the time to talk about
expanding the operator set. I'd be very surprised if it happens
before 3.0, and very surprised if it isn't one of the major
features in that same rather vague 3.0 release.
On the other hand, I'm hoping (without much expectation)
that we decide that 2.3 will be followed by 3.0. I've got a
little list... (with apologies to Gilbert and Sullivan.)
John Roth
Alan Gauld
Arthur St. Marie II of III ) wrote:
> Doc\ref 2.6 Delimiters show's three unused characters "@ $ ?".
> @ sort of looks like and sort of sounds like a set an
> $ well sort of obvious.
> I can imagine that the $ would be confused for money and @ is ugly.
Since I detest any thought of prefix symbols to indicate type(as
per Perl etc) but have no visibility of these debates, I'll throw
in my suggestion and done a flameproof suit!
Since both dictionaries and Sets require unique members/keys,
why not use the dictionary braces but without the key/value
syntax. So:
mySet = {1,2,3,4}
Which is illegal for a dictionary but would be OK for a Set.
It also just happens to be the same delimiters used in math
for sets...
Just a thought before I go to bed! :-)
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
Carl Banks
+1 if Python's parser could handle it (which seems dubious).
--
CARL BANKS
Inyeol Lee
[...]
> Since both dictionaries and Sets require unique members/keys,
> why not use the dictionary braces but without the key/value
> syntax. So:
>
> mySet = {1,2,3,4}
>
> Which is illegal for a dictionary but would be OK for a Set.
> It also just happens to be the same delimiters used in math
> for sets...
See PEP 218. It describes a long term plan to make set builtin type,
including syntax for constant set {1,2,3,4} and empty set {-}.
Inyeol
Raymond Hettinger
> > why not use the dictionary braces but without the key/value
> > syntax. So:
> >
> > mySet = {1,2,3,4}
> >
> > Which is illegal for a dictionary but would be OK for a Set.
> > It also just happens to be the same delimiters used in math
> > for sets...
>
>
> +1 if Python's parser could handle it (which seems dubious).
FWIW, I think the easiest and most readable syntax is:
mySet = set(1, 2, 3, 4)
BTW, this is a bit reminiscent of the discussion about a syntax
for entering fixed decimals. After much discussion, someone
realized the obvious and noted that real programs mostly
take in their fixed point data from external sources and would
rarely appear as a constant in a program; hence, there was no
need for a special syntax -- just Decimal(data) would do the
trick. (Think about a program like Quicken for checkbook
accounting -- none of the check/deposit amounts are known
in advance so the program is unlikely to contain any fixed
decimal constants except zero and $0.01).
Raymond Hettinger