472,805 Members | 923 Online

# Why tuples use parentheses ()'s instead of something else like <>'s?

Tuples are defined with regards to parentheses ()'s as everyone knows.

This causes confusion for 1 item tuples since (5) can be interpreted
as a tuple OR as the number 5 in a mathematical expression
such as x = (5) * (4+6).

Wouldn't it have been better to define tuples with <>'s or {}'s or
something else to avoid this confusion??

Perhaps ()'s are a good idea for some other reason I don't know?

Please enlighten me as I really want to know.
Chris

P.S. I love Python!

Jul 18 '05 #1
44 3214
se******@spawar.navy.mil wrote:
Tuples are defined with regards to parentheses ()'s as everyone knows.

This causes confusion for 1 item tuples since (5) can be interpreted
as a tuple OR as the number 5 in a mathematical expression
such as x = (5) * (4+6).
No, (5) is always the number 5. To make a one-element tuple, use (5,).
Wouldn't it have been better to define tuples with <>'s or {}'s or
something else to avoid this confusion??

Perhaps ()'s are a good idea for some other reason I don't know?

Actually, for non-empty tuples, the parentheses aren't really necessary,
unless code is ambiguous.
x = 1, 2, 3
x (1, 2, 3) y = 5,
y (5,)

but:
print 8, 9 # not a tuple 8 9 print (8, 9)

(8, 9)

HTH,

--
Hans Nowak
http://zephyrfalcon.org/

Jul 18 '05 #2
se******@spawar.navy.mil wrote:
Wouldn't it have been better to define tuples with <>'s or {}'s or
something else to avoid this confusion??

The way I see it, tuples are just a way of having a function return
multiple values at once. When you think of them that way, you don't even
need parenthesis:

def foo():
if we_found_stuff:
return 200, 'long and boring result'
else:
return 404, 'nothing found'

status_code, body = foo()

If foo() only needed to return one value, it would do so in the normal
way, and you wouldn't need to worry about 1-tuples.
Jul 18 '05 #3
* se******@spawar.navy.mil
Perhaps ()'s are a good idea for some other reason I don't know?

One-element tuples are written as (4,).

--
Marius Bernklev

<URL: http://www.ping.uio.no/~mariube/ >

Jul 18 '05 #4
se******@spawar.navy.mil <se******@spawar.navy.mil> wrote:
Tuples are defined with regards to parentheses ()'s as everyone knows.
Well, then, "everyone knows" wrong:

x = 1, 2, 3

x is a tuple. The _commas_ make it one -- parentheses don't matter.

An _empty_ tuple uses parentheses, (), as there's nowhere to put commas;
and you need parentheses AROUND the tuple-with-commas when the commas by
themselves would be interpreted otherwise (function definition and call,
except clause). But generally, the commas are what mattes.

This causes confusion for 1 item tuples since (5) can be interpreted
as a tuple OR as the number 5 in a mathematical expression
Nah: no commas, no tuple. To set x to a one-item tuple:

x = 5,

feel free to put useless parentheses around the RHS, they don't hurt.
But the comma MUST be there.
Wouldn't it have been better to define tuples with <>'s or {}'s or
something else to avoid this confusion??
Instead of commas? I think it would look weird.
Perhaps ()'s are a good idea for some other reason I don't know?

They're somewhat overloaded, and so are commas. There just isn't enough
neat-looking punctuation in the ASCII character set.
Alex
Jul 18 '05 #5
se******@spawar.navy.mil wrote:
Wouldn't it have been better to define tuples with <>'s or {}'s or
something else to avoid this confusion??

Well, to comment on the part that nobody else did...
< and > are binary operators, a la 3 > 1, "one" < "two"
and {}'s are clearly already used for dictionaries.

--
Brian Beck
Jul 18 '05 #6
Marius Bernklev wrote:
* se******@spawar.navy.mil

Perhaps ()'s are a good idea for some other reason I don't know?

One-element tuples are written as (4,).

And, even there, the parenthesis is only required when it would
otherwise be embiguous:
x = 4,
x (4,) print 4, 4

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Jul 18 '05 #7

<se******@spawar.navy.mil> wrote in message
Tuples are defined with regards to parentheses ()'s as everyone knows.
To expand on what Alex Martelli said:

Tuples don't use parentheses except for the special case of the
empty tuple. Those are expression parentheses. The two most
obvious cases of this are in the return statement and sequence
unpacking in assignment statements.

Grouping syntax is used for both unary operators and operands.
Parentheses are used for expressions (operands) and
function/method parameter lists (operators). Brackets ([])
are used for lists (operands) and subscripts/slices (operators).
Braces ({}) are used for dictionarys (operands). They aren't
currently used for unary operators.

John Roth
Please enlighten me as I really want to know.
Chris

P.S. I love Python!

Jul 18 '05 #8
On 2004-12-29, se******@spawar.navy.mil <se******@spawar.navy.mil> wrote:
Tuples are defined with regards to parentheses ()'s as everyone knows.

Except they're not.
x = 1,2,3,4
type(x) <type 'tuple'>

Tuples are defined by the infix comma "operator".

--
Grant Edwards grante Yow! I'm working under
at the direct orders of WAYNE
visi.com NEWTON to deport consenting
Jul 18 '05 #9
In article <41***********************@visi.com>,
Grant Edwards <gr****@visi.com> wrote:
On 2004-12-29, se******@spawar.navy.mil <se******@spawar.navy.mil> wrote:
Tuples are defined with regards to parentheses ()'s as everyone knows.

Except they're not.
x = 1,2,3,4
type(x) <type 'tuple'>

Tuples are defined by the infix comma "operator".

Well, the syntax is a little more complicated than that. Commas don't
form tuples in a lot of places:

f (1, 2, 3) # function call gets three scalar arguments
[1, 2, 3] # list of three integers, not list of tuple
[x, 1 for x in blah] # syntax error, needs to be [(x, 1) for ...]

I'm sure there are others. The meaning of "," depends on the context in
which it appears. In most cases, the parens around tuples are optional
except when necessary to disambiguate, but there's one degenerate
special case, the empty tuple (zerople?), where the parens are always
required. It's just one of those little warts you have to live with.

If Python had originally been invented in a unicode world, I suppose we
wouldn't have this problem. We'd just be using guillemots for tuples
(and have keyboards which made it easy to type them).
Jul 18 '05 #10

"Roy Smith" <ro*@panix.com> wrote in message
In article <41***********************@visi.com>,
Grant Edwards <gr****@visi.com> wrote:
On 2004-12-29, se******@spawar.navy.mil <se******@spawar.navy.mil> wrote:
> Tuples are defined with regards to parentheses ()'s as everyone knows.
Except they're not.
>>> x = 1,2,3,4
>>> type(x)

<type 'tuple'>
>>>

Tuples are defined by the infix comma "operator".

Well, the syntax is a little more complicated than that. Commas don't
form tuples in a lot of places:

f (1, 2, 3) # function call gets three scalar arguments
[1, 2, 3] # list of three integers, not list of tuple
[x, 1 for x in blah] # syntax error, needs to be [(x, 1) for ...]

I'm sure there are others. The meaning of "," depends on the context in
which it appears.

This is true, however all three cases you mention are part
of the grammar. In any case, the function call syntax isn't
dependent on it following a function name; it's dependent
on it appearing where an operator is expected in the
expression syntax.
In most cases, the parens around tuples are optional
except when necessary to disambiguate, but there's one degenerate
special case, the empty tuple (zerople?), where the parens are always
required. It's just one of those little warts you have to live with.
That one doesn't require the comma, either. It's a very definite
special case.
If Python had originally been invented in a unicode world, I suppose we
wouldn't have this problem. We'd just be using guillemots for tuples
(and have keyboards which made it easy to type them).

I suppose the forces of darkness will forever keep Python from
requiring utf-8 as the source encoding. If I didn't make a fetish
of trying to see the good in everybody's position, I could really
work up a dislike of the notion that you should be able to use
any old text editor for Python source.

There are a lot of Unicode characters that would be quite
helpful as operators. A left pointing arrow would be a vast
improvement over the equal sign for assignment, for example.
There wouldn't be any chance of mixing it up with the double
equal for comparisons. The same thing goes for multiplication
and division. We've allowed ourselves to be limited by the
ASCII character set for so long that improving that seems to be
outside of most people's boxes.

John Roth

Jul 18 '05 #11
"John Roth" <ne********@jhrothjr.com> wrote:
If Python had originally been invented in a unicode world, I suppose we
wouldn't have this problem. We'd just be using guillemots for tuples
(and have keyboards which made it easy to type them).

I suppose the forces of darkness will forever keep Python from
requiring utf-8 as the source encoding. If I didn't make a fetish
of trying to see the good in everybody's position, I could really
work up a dislike of the notion that you should be able to use
any old text editor for Python source.

You can't use "any old text editor" for Python source. You can only use
a hardware/software combination which supports the required character
set (which AFAICT means ASCII, including *both* cases of the alphabet).
You would probably find it difficult to enter Python code on a 029
keypunch, or an ASR-33, or even an IBM-3270.

Granted, those are all dinosaurs these days, but 30 years ago, they
represented the norm. At that time, C was just hitting the streets, and
it was a pain to edit on many systems because it used weird characters
like { and }, which weren't in EBCDIC, or RAD-50, or SIXBIT, or whatever
character set your system used. ASCII was supposed to solve that
nonsense once and for all, except of course for the minor problem that
it didn't let most people in the world spell their names properly (if at
all).

In any case, it's a good thing that Python can be edited with "any old
text editor", because that lowers the price of entry. I like emacs, the
next guy likes vi, or vim, or notepad, or whatever. Nothing is keeping
folks who like IDEs from inventing and using them, but I would have been
a lot less likely to experiment with Python the first time if it meant
getting one of them going just so I could run "Hello, world".

With google as my witness, I predict that in 30 years from now, ASCII
will be as much a dinosaur as a keypunch is today, and our children and
grandchildren will both wonder how their ancestors ever managed to write
programs without guillemots and be annoyed that they actually have to
type on a keyboard to make the computer understand them.
Jul 18 '05 #12
Roy Smith wrote:
"John Roth" <ne********@jhrothjr.com> wrote:
> If Python had originally been invented in a unicode world, I suppose we
> wouldn't have this problem. We'd just be using guillemots for tuples
> (and have keyboards which made it easy to type them).
I suppose the forces of darkness will forever keep Python from
requiring utf-8 as the source encoding. If I didn't make a fetish
of trying to see the good in everybody's position, I could really
work up a dislike of the notion that you should be able to use
any old text editor for Python source.

In any case, it's a good thing that Python can be edited with "any old
text editor", because that lowers the price of entry. I like emacs, the
next guy likes vi, or vim, or notepad, or whatever. Nothing is keeping
folks who like IDEs from inventing and using them, but I would have been
a lot less likely to experiment with Python the first time if it meant
getting one of them going just so I could run "Hello, world".
Perl6 experiments with the use of guillemots as part of the syntax. I
shall be curious to see how this is accepted, of course only if Perl6 is
ever going to see the light of day, which is an exciting matter of its
own...
With google as my witness, I predict that in 30 years from now, ASCII
will be as much a dinosaur as a keypunch is today, and our children and
grandchildren will both wonder how their ancestors ever managed to write
programs without guillemots and be annoyed that they actually have to
type on a keyboard to make the computer understand them.

Well, it's not clear if they will still "write" programs...

Reinhold
Jul 18 '05 #13
On 2004-12-29, Reinhold Birkenfeld <re************************@wolke7.net> wrote:
Perl6 experiments with the use of guillemots as part of the syntax.

As if Perl didn't look like bird-tracks already...

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidli...Uria_aalge.htm

--
Grant Edwards grante Yow! There's enough money
at here to buy 5000 cans of
visi.com Noodle-Roni!
Jul 18 '05 #14
se******@spawar.navy.mil wrote:
Why tuples use parentheses ()'s instead of something else like <>'s?

Please enlighten me as I really want to know.

So to summarize:

Commas define tuples, except when they don't, and parentheses are only
required when they are necessary.

I hope that clears up any confusion.
Jul 18 '05 #15
Grant Edwards wrote:
On 2004-12-29, Reinhold Birkenfeld <re************************@wolke7.net> wrote:
Perl6 experiments with the use of guillemots as part of the syntax.

As if Perl didn't look like bird-tracks already...

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidli...Uria_aalge.htm

Well,

(1,1,2,3,5) »+« (1,2,3,5,8); # results in (2,3,5,8,13)

(>>+<< being an operator) just isn't something I would like to read in
my code...

Reinhold
Jul 18 '05 #16
In article <33*************@individual.net>,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:
+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"
Jul 18 '05 #17
On 2004-12-29, Reinhold Birkenfeld <re************************@wolke7.net> wrote:
Perl6 experiments with the use of guillemots as part of the syntax.

As if Perl didn't look like bird-tracks already...

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidli...Uria_aalge.htm

Well,

(1,1,2,3,5) »+« (1,2,3,5,8); # results in (2,3,5,8,13)

I was pretty sure that « and » were guillmots, but google sure
preferred the sea bird when I asked it.

--
Grant Edwards grante Yow! I've been WRITING
at to SOPHIA LOREN every 45
visi.com MINUTES since JANUARY 1ST!!
Jul 18 '05 #18
On 29 Dec 2004 21:03:59 GMT,
Grant Edwards <gr****@visi.com> wrote:
On 2004-12-29, Reinhold Birkenfeld <re************************@wolke7.net> wrote:
Perl6 experiments with the use of guillemots as part of the syntax.

As if Perl didn't look like bird-tracks already...

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidli...Uria_aalge.htm
Well,

(1,1,2,3,5) Â»+Â« (1,2,3,5,8); # results in (2,3,5,8,13)

I was pretty sure that Â« and Â» were guillmots, but google sure
preferred the sea bird when I asked it.

They're guillemets (with an "e"); this is a [relatively] well-known
Adobe SNAFU. (A quick google search or two failed to find an
authoritative reference, but I know that such references are out there
somewhere.)

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.
Jul 18 '05 #19
> There just isn't enough
neat-looking punctuation in the ASCII character set.

Alex

I can't thank you enough for your reply and for everyones' great info
on this thread. The end of your email gave a rock solid reason why it
is impossible to improve upon ()'s for tuples....

*There simply isn't enough good candidates in ASCII.*

Moving to Unicode has pros
and cons but your defense of parens assuming ASCII is perfect.
Thanks again.

Chris

Jul 18 '05 #20
Brian

I am so thankful for your reply and for Alex's and everyone else's on
this thread. (See my reply to Alex.) This email may seem minor but it
was bugging me for months. You just
pointed out what I should have remembered on my own...

*<>'s wouldn't have been a perfect choice because they would have had
their
own unique gotchas involving accidentally interpreting them as binary
shift operators*

I really appreciate it.

Chris

Jul 18 '05 #21
On 2004-12-29, Dan Sommers <me@privacy.net> wrote:
They're guillemets (with an "e"); this is a [relatively] well-known

Ah. Googling for "guillemots punctuation" did turn up enough
hits that it didn't occur to me that I was using the wrong
spelling.

--
Grant Edwards grante Yow!
at TAILFINS!!... click...
visi.com
Jul 18 '05 #22
Dan Sommers wrote:
On 29 Dec 2004 21:03:59 GMT,
Grant Edwards <gr****@visi.com> wrote:

On 2004-12-29, Reinhold Birkenfeld <re************************@wolke7.net> wrote:
>Perl6 experiments with the use of guillemots as part of the syntax.

As if Perl didn't look like bird-tracks already...

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidli...Uria_aalge.htm

Well,

(1,1,2,3,5) Â»+Â« (1,2,3,5,8); # results in (2,3,5,8,13)

I was pretty sure that Â« and Â» were guillmots, but google sure
preferred the sea bird when I asked it.

They're guillemets (with an "e"); this is a [relatively] well-known
Adobe SNAFU. (A quick google search or two failed to find an
authoritative reference, but I know that such references are out there
somewhere.)

Regards,
Dan

Adobe recorded their error in the Red Book errata, but electronic
admissions of the same error are apparently impossible to come by.

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Jul 18 '05 #23
Roy Smith <ro*@panix.com> wrote:
In article <33*************@individual.net>,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:
>>+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"

You know Ben Yalow?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
Jul 18 '05 #24
John Roth wrote:

"Roy Smith" <ro*@panix.com> wrote in message
If Python had originally been invented in a unicode world, I suppose we
wouldn't have this problem. We'd just be using guillemots for tuples
(and have keyboards which made it easy to type them).

I suppose the forces of darkness will forever keep Python from
requiring utf-8 as the source encoding. If I didn't make a fetish
of trying to see the good in everybody's position, I could really
work up a dislike of the notion that you should be able to use
any old text editor for Python source.

It's not so much the desire to be able to use any old text editor that
keeps Python in ASCII, it's the desire to use any old *hardware*.
Keyboards with guillemots are not exactly a worldwide norm, and needing
to remember and type some arcane alt-keycode formula to be able to do
basic scripting would be obnoxious, to say the least. Most keyboards
worldwide provide decent support for the ASCII character set (though
some add a few extra national characters). Perhaps things will change
when a majority of the world's programmers use a non-Roman alphabet /
character set, but even then there's a significant weight of historical
reasons to overcome.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #25
In article <cq**********@panix3.panix.com>, aa**@pythoncraft.com (Aahz)
wrote:
Roy Smith <ro*@panix.com> wrote:
In article <33*************@individual.net>,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:

>>+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"

You know Ben Yalow?

I once had a physics professor named Aaron Yalow, but I can't say I know
any Ben Yalow.
Jul 18 '05 #26
Roy Smith <ro*@panix.com> wrote:
In article <cq**********@panix3.panix.com>, aa**@pythoncraft.com (Aahz)
wrote:
Roy Smith <ro*@panix.com> wrote:
In article <33*************@individual.net>,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:

>>+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"

You know Ben Yalow?

I once had a physics professor named Aaron Yalow, but I can't say I know
any Ben Yalow.

Heh. Someone in NYC fandom known for wearing a bowtie.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

And "fandom" of course refers to "science fiction fandom"
Jul 18 '05 #27
In article <cq**********@panix3.panix.com>, aa**@pythoncraft.com (Aahz)
wrote:
Roy Smith <ro*@panix.com> wrote:
In article <cq**********@panix3.panix.com>, aa**@pythoncraft.com (Aahz)
wrote:
Roy Smith <ro*@panix.com> wrote:
In article <33*************@individual.net>,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:
>
> >>+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"

You know Ben Yalow?

I once had a physics professor named Aaron Yalow, but I can't say I know
any Ben Yalow.

Heh. Someone in NYC fandom known for wearing a bowtie.

Interesting. It would appear that Ben's father was my physics professor
(http://www.meetingnews.com/meetingne...ay.jsp?vnu_con
tent_id=1749837). I do not recall what style of neckwear he favored.

Small world, huh?
Jul 18 '05 #28
On Dec 29, 2004, at 3:38 PM, Rocco Moretti wrote:
So to summarize:

Commas define tuples, except when they don't, and parentheses are only
required when they are necessary.

Exactly! Now can we clear anything else up for you? ;-)

___/
/
__/
/
____/
Ed Leafe
http://leafe.com/
http://dabodev.com/

Jul 18 '05 #29
Ed Leafe wrote:
Exactly! Now can we clear anything else up for you? ;-)

How about a computer program than can correctly count the number of letter E's

Cheers,
Nick.
I like the sig, if you hadn't guessed. . .

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Jul 18 '05 #30
Rocco Moretti wrote:
So to summarize:

Commas define tuples, except when they don't, and parentheses are only
required when they are necessary.

I hope that clears up any confusion.

You have my vote for QOTW.

--
"Codito ergo sum"
Roel Schroeven
Jul 18 '05 #31
John Roth <ne********@jhrothjr.com> wrote:
...
and division. We've allowed ourselves to be limited by the
ASCII character set for so long that improving that seems to be
outside of most people's boxes.

APL didn't allow itself to be limited that way. Anybody who's used it
can hardly be accused to keep non-ASCII characters "outside their box".

And, you know what? Despite being an old APL user, I think would be a
_disaster_ for Python to go that route. Yes, ASCII imposes design
constraints. But constraints can be a good and helpful thing. Look for
example at what classical architects and sculptors DID, within horrible
technical constraints on materials and methods, and compare it with
artsy modern architecture, which can use an enormously wider palette of
technical approaches and materials... I think a tiny minority of today's
architecture and sculpture can rightfully be compared with the
masterpieces of millennia past. Similarly, highly constrained forms
such as sonnet or haiku can unchain a poet's creativity in part BECAUSE
of the strict constraints they impose wrt free verse or prose...

Back to feet-on-ground issues, mandating a wider-than-ASCII character
set would horribly limit the set of devices, as well as of software
tools, usable with/for Python -- I love the fact that Python runs on
cellphones, for example. Input methods for characters outside the ASCII
set are always a bother, particularly to the touch-typist: even to enter
Italian accented vowels, on this US keyboard, I have to go through
definitely eccessive gyrations, which horribly slow down my usually very
fast typing. Seeing what you're doing can sometimes be a bother too:
you need to ensure the glyphs for all the characters you need are
readable _and distinguishable_ in whatever font you're using.
Alex
Jul 18 '05 #32
Dan Sommers <me@privacy.net> wrote:
...
I was pretty sure that « and » were guillmots, but google sure
preferred the sea bird when I asked it.

They're guillemets (with an "e"); this is a [relatively] well-known
Adobe SNAFU. (A quick google search or two failed to find an
authoritative reference, but I know that such references are out there
somewhere.)

Ameritan Heritage dictionary:
SYLLABICATION:
guil·le·met

PRONUNCIATION:
gl-mt, g--m

NOUN:
Either of a pair of punctuation marks («) or (») used in some
languages, such as French and Russian, to mark the beginning and end of
a quotation.
SYLLABICATION:
guil·le·mot

PRONUNCIATION:
gl-mt

NOUN:
Any of several auks of the genus Cepphus, having black plumage with
white markings.
Both come from the French name "Guillaume" (William), but they happened
to pass into English with slightly different spellings. (I find
American Heritage to be a very authoritative reference -- I just love
it!-).
Alex
Jul 18 '05 #33
Jeff Shannon <je**@ccvcorp.com> wrote:
...
to remember and type some arcane alt-keycode formula to be able to do
basic scripting would be obnoxious, to say the least. Most keyboards
worldwide provide decent support for the ASCII character set (though
some add a few extra national characters). Perhaps things will change

Italian-layout support for braces is the pits (alt-keycodes ahoy): one
way I managed to get a local friend interested in Python was to point
out that he'd neved NEED to type braces (calling `dict' is just as good
a way to make dictionaries, as braces-laden `dict display' forms;-).
Alex
Jul 18 '05 #34
On Thu, 30 Dec 2004 15:58:07 GMT, Roel Schroeven wrote:
Rocco Moretti wrote:
So to summarize:

Commas define tuples, except when they don't, and parentheses are only
required when they are necessary.

I hope that clears up any confusion.

You have my vote for QOTW.

+1
:-)

--
Un sens interdit ne l'est formellement et réellement que s'il est, non
moins formellement et non moins réellement, unique en sens inverse.
(Pierre Dac)
Jul 18 '05 #35
Alex Martelli wrote:
Jeff Shannon <je**@ccvcorp.com> wrote:
...
to remember and type some arcane alt-keycode formula to be able to do
basic scripting would be obnoxious, to say the least. Most keyboards
worldwide provide decent support for the ASCII character set (though
some add a few extra national characters). Perhaps things will change

Italian-layout support for braces is the pits (alt-keycodes ahoy): one
way I managed to get a local friend interested in Python was to point
out that he'd neved NEED to type braces (calling `dict' is just as good
a way to make dictionaries, as braces-laden `dict display' forms;-).

That's equally true for the German keyboard layout, though I believe
that most programmers switch to standard English layout anyway.

Reinhold
Jul 18 '05 #36
Alex Martellix wrote:
I think a tiny minority of today's
architecture and sculpture can rightfully be compared with the
masterpieces of millennia past.

Not that I disagree with your overall point, but I suspect a tiny
minority of the architecture and sculpture from millenia past can be
rightfully compared with the masterpieces of millenia past.

Then again, millenia past didn't have Frank Gehry (i.e., the Perl of
modern architecture).
--
CARL BANKS

Jul 18 '05 #37
Carl Banks <im*****@aerojockey.com> wrote:
Alex Martellix wrote:
I think a tiny minority of today's
architecture and sculpture can rightfully be compared with the
masterpieces of millennia past.
Not that I disagree with your overall point, but I suspect a tiny
minority of the architecture and sculpture from millenia past can be
rightfully compared with the masterpieces of millenia past.

True. Most forgettable architecture has fortunately crumbled to
dust;-).

Still -- there's more of that from millennia past than one might think.

I was walking back from grocery shopping today (my daughter having
borrowed my car, I had to walk to the market and back), and I noticed a
new display in a familiar courtyard.

Finally, over 90 years after the original discoveries, they've built a
display showcase of the two major pre-Etruscan necropolises -- San
Vitale and Savena -- which were discovered before WW 1, when
urbanization was first done on the neighborhood I was born in, the same
place I currently live in.

About 3000 years ago, with little beyond dried mud (the Bologna region
was never rich in anything but clay, as building materials go -- and at
that time they didn't fire-bake clay into bricks, not regularly,
anyway), and wood long since rotten, some unknown, unsung architects put
together a small town for the dead, right below the sidewalks I thread
every day.

My breath was taken away by finally seeing some of their work on display
in its rightful place, my birthplace and residence, as opposed to the
museums (several blocks away) where it's generally gathering dust in.

Have you heard of Villanova, often named as the birthplace of Italian
civilization? That's about 15 km away, where I generally go for major
grocery shopping at a hypermarket when I _do_ have a car. San Vitale
and Savena were way older, more primitive, more essential -- no jewels
of gold and amber to gawp at, yet... the pre-Etruscans,
pre-Villanovians, still hadn't managed yet to get in gear with the
system of commerce and European- and Mediterranean-wide exhanges which
later made Etruria the beacon of arts and culture. Within the
constraints of a still rather poor material culture, the necropolises of
Savena and San Vitale nevertheless exhibit the kind of limpid, geometric
symmetry, spiritual balance, and minimalistic play of emptiness and
fullness, that _defines_ worthwhile architecture to my soul...

How many more jewels like this one are still buried under the soil of
Italy (to name just one place, albeit a rather fecund one for that kind
of thing)? Nobody knows -- basically, every time you're excavating
something, be it to lay foundations for a warehouse or whatever, among
your risks as a developer is that the first few shovelfuls will reveal
*yet one more* previously unsuspected architectural and archeological
treasure, so that your development will be blocked and stalled for
years, decades, while the duly appointed officials salvage all that's
there. Why, even when you're restoring an already well-known
architectural masterpiece from the Renaissance, you STILL risk finding a
well-preserved marble amphitheater from Roman times that the Renaissance
architects used as part of their _foundations_... happened downtown in
Bologna just over 10 years ago -- and Bologna was a somewhat marginal
provincial town 2000 or so years ago: just imagine what it must be like
as you move southwards through Tuscany towards the heart of Roman
culture in Lazio...! ((Being Italian, I tend to focus on the way things
are here -- but I heard the projects to restore the city walls in
Instambul, aka Bizantium, came upon exactly the same kinds of problems
over the last 20+ years... Italy certainly has no monopoly on having
layers upon layers upon layers of great architecture and civilization!))

Then again, millenia past didn't have Frank Gehry (i.e., the Perl of
modern architecture).

Uhm -- I count the Guggenheim Museum in Bilbao among the _successes_ of
modern architecture... yes, it IS rich and redundant and wild and self
complacent... it _should_ be, much like (say) the Pantheon or Saint
Peter's in Rome, or Saint Nicholas in Prague (and other masterpieces of
Flaming Baroque, "Il Barocco di fiamma")... not ALL great art is
minimalistic and spare and understated! _Some_ of the time, an artist
manages to overwhelm you with perfect mastery of overflowing richness...
like, say, Bach's Matthauspassion's richness, wrt the spareness his Art
of the Fugue... all I'm saying is that material or formal constraints
can HELP art, not that they're necessarily _indispensable_ to it...
Alex
Jul 18 '05 #38
Alex Martelli wrote:
Carl Banks <im*****@aerojockey.com> wrote:
Then again, millenia past didn't have Frank Gehry (i.e., the Perl of
modern architecture).

Uhm -- I count the Guggenheim Museum in Bilbao among the _successes_ of
modern architecture...

I'll give you the Bilbao Guggenheim, which (at least in the exterior
pictures I can find) is a very attractive building, but here in
Seattle we must deal with the giant eyesore that is Gehry's Experience
Music Project, which (at least to my eyes) looks like a monstrous pile
of architectural rubbish. I can appreciate Gehry's attempts to get
away from the tyranny of the straight line, and even with the EMP
there's certain details which turned out well, but the overall effect
is that of an overturned garbage pail.

Jeff Shannon
Technician/Programmer
Credit International

Jul 18 '05 #39
Jeff Shannon wrote:
Alex Martelli wrote:
Carl Banks <im*****@aerojockey.com> wrote:
Then again, millenia past didn't have Frank Gehry (i.e., the Perl of
modern architecture).

Uhm -- I count the Guggenheim Museum in Bilbao among the _successes_ of
modern architecture...

I'll give you the Bilbao Guggenheim, which (at least in the exterior
pictures I can find) is a very attractive building, but here in Seattle
we must deal with the giant eyesore that is Gehry's Experience Music
Project, which (at least to my eyes) looks like a monstrous pile of
architectural rubbish. I can appreciate Gehry's attempts to get away
from the tyranny of the straight line, and even with the EMP there's
certain details which turned out well, but the overall effect is that of
an overturned garbage pail.

My wife, who's a commercila property manager, holds that many of the
worst architectural excesses were designed as monuments to the architect
rather that to fulfil the operational needs of the occupier.

Come to think, I can remember at least one shitty piece of software that
was designed on the same principles, but thankfully it's now over seven
years since I worked in *that* environment.

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Jul 18 '05 #40
Hi all,

a question about using parenthesis for tuples veered very far off topic
before I returned from a trip and found the thread. I've a comment on
the original topic, and then a comment off-topic even for the off-topic
direction in which the thread ended up :-)

The on-topic:

the use of '(' and ')' for tuples really did jar me. With a background
in set-theory, I expected tuples to look like <1, 2, 3>. It took a
little bit to reset my brain.

I am aware that even some set theory material is starting to use rounded
brackets for tuples. With this I can cope (barely). But, just yesterday,
I was reading an otherwise fine book on relevance logic marred by its
use of both angle and round brackets for tuples, with no apparent
principle other than the coin toss determining which to use when. The
horror!

The off-topic**2:

Alex Martelli said unto the world upon 2004-12-30 19:09:

<SNIP>
Have you heard of Villanova, often named as the birthplace of Italian
civilization? That's about 15 km away, where I generally go for major
grocery shopping at a hypermarket when I _do_ have a car.
<SNIP>
Alex

'Hypermarket' is a new one to me, but seems instantly understandable. It

Italy isn't my country, but for the past few years I've been lucky
enough to spend a month or so in the north each year. In the short time
I've been doing so, I think I've been able to detect the decline of the
small independent shops and the rampant growth of the american style
mall, big-box store and mutilplex.

The small store to which you can walk and where you likely know the
vendor, and even if you don't, run the real risk of having a
conversation, seems a thing worth trying to preserve. They surely aren't
as efficient as the north-american model, but one of the nicest things
about Italian culture IMHO is that it appears to understand that some
things are at least as important as efficiency.

And it is truly heart-breaking to see the beautiful countryside around
Italian towns being defaced by large fields of blacktop.

Luddites of the world unite!

Happy New Year to all,

Brian vdB

Jul 18 '05 #41
Brian van den Broek <bv****@po-box.mcgill.ca> wrote:
...
Have you heard of Villanova, often named as the birthplace of Italian
civilization? That's about 15 km away, where I generally go for major
grocery shopping at a hypermarket when I _do_ have a car.
<SNIP>
Alex

'Hypermarket' is a new one to me, but seems instantly understandable. It

Ah, yes, I understand what you mean.
Italy isn't my country, but for the past few years I've been lucky
enough to spend a month or so in the north each year. In the short time
I've been doing so, I think I've been able to detect the decline of the
small independent shops and the rampant growth of the american style
mall, big-box store and mutilplex.
To some extent, yes. 40 years ago, when I was a kid, I knew of about a
dozen small shops of each kind (butcher, baker, grocer, etc -- each
would sell only and strictly its specific wares; you'd go to different
specialized butchers for beef and pig, versus poultry, versus horsemeat,
etc; ...) which were well within walking distance, in addition to two
open-air markets. Nowadays, living in the same place where I grew up, I
only know of about four small shops of each kind (but each does sell
more kinds of wares than of yore) and the same two markets (now with
some cover against rain, though still essentially open-air) -- plus
three minimarkets owned and managed by immigrants (so that when on
Christmas day I found out I was out of fruit juice, I _could_ easily
find an _open_ nearby store to buy more;-), and a mid-size supermarket.
But yes, all in all, there has been some noticeable reduction in the
number and variety of small nearby stores.

Many have been replaced by places selling takeaway pizza, falafel,
gyros, kebab, and the like -- considering that my home is very close to
the University quarter of town and the whole neighborhood has been
filling up with students living off campus for over 20 years, I find
that hardly surprising. The typical student is far likelier to want a
say, a pot roast. People who do buy the latter, like me, are likelier
to plan in advance, to have a car, and to be willing to drive 20 minutes
or so to get to a hypermarket, for the small savings (compared to the
mid-sized supermarket that's walking distance) and the vaster choice
(only place I can get really good AND decent priced organic-grown
grapefruit juice, for example).

The small store to which you can walk and where you likely know the
vendor, and even if you don't, run the real risk of having a
conversation, seems a thing worth trying to preserve. They surely aren't
as efficient as the north-american model, but one of the nicest things
about Italian culture IMHO is that it appears to understand that some
things are at least as important as efficiency.
The falafel seller is quite as likely to start up a conversation as the
poultry-only butcher that used to be there 30 years ago, although
admittedly it does work better if you speak some rudiments of Arabic
(which, alas, I don't). And the NA model, where it works right
(requiring _some_ density of population -- it just can't work right
where population is too thinly spread), offers you *choice*, just like
the variant that's growing in my part of Italy. If you live in Old Palo
Alto, say, you get quite a choice of small shops and open-air markets
(with higher prevalence of organic produce than is common here yet) in
walking distance, as well as the ability to get into a car and go for
cheaper bulk shopping. Of course, if you live in cheaper, more
spacious, endless-sprawling exurbia, there's *nothing* in walking
distance... that's the inevitable price of wanting that spaciousness,
see: it spreads things out. Many Americans who can afford to do
otherwise would find it unbearably crowded to live in big apartment
buildings, as a vast majority of the population does here; yet if every
family had its own detached house, with garden and backyard, *boom*,
sprawl. Geometry just won't be dictated to, see: multi-storied
apartment buildings and a scarcity of gardens is the flipside of the
population density which allows small walking-distance shops to thrive,
and, viceversa, hateful endless sprawl the flip side of everybody having
nice gardens etc.

All in all efficiency is best served by the Italian (and generally
European) preference for crowded cities of apartment buildings over
suburbia and exurbia -- we save a lot of driving that way. But as my
long-term dream is STILL to restore grandfather's house in the
countryside and retire there, I can hardly speak against the desire for
space all around you;).

And it is truly heart-breaking to see the beautiful countryside around
Italian towns being defaced by large fields of blacktop.
The beautiful parts of Bologna's countryside (southwards, towards the
Appennines -- Bologna is halfway up on the foothills of the Appennines,
already) are hardly defaced by anything... it just wouldn't be
practical. All the hypermarkets &c are northwards, towards the plains
(Pianura Padana), the not-so-beautiful part (the same part which filled
up with factories 100+ years ago, actually, and for similar reasons:
it's very flat, which makes good wide roads quite practical, though it
has nowhere like the beauty of the rugged hilly south side of town &
surroundings;-).
Luddites of the world unite!
Making everybody have a single-family home with nice garden and backyard
to ensure sprawl?-)

IOW, I think you have causation the wrong way 'round. Small stores are
and remain practical, even if not with the density we used to have 40
years ago, when population density makes them so; and it's demand which
mostly drives -- in France, everything may be closed on Sunday,
including gas stations, but you'll ALWAYS find a baker open with freshly
made baguettes on Sunday morning, cause the French consumers just won't
stand for one day old bread; Italians are less particular about that, so
bakers do close on Sundays here. You can't change people's preferences
bakers must or must not open on Sundays. Just let the market work (with
decent levels of safety net, to be sure -- hey, I _am_ a European!) and
it will roughly adjust to what people _actually_ want enough to vote
with their wallets -- be it fresh bread or cheap bread, yummy organic
freshly squeezed juices or cheap industrial juices available for sale on
Christmas day, spacious gardens and backyards or the many efficiency
advantages of crowded apartment buildings stacked next to each other...

Happy New Year to all,

Same here!
Alex
Jul 18 '05 #42
Roel Schroeven wrote:
Rocco Moretti wrote:
So to summarize:
Commas define tuples, except when they don't, and parentheses are only
required when they are necessary.
I hope that clears up any confusion.

You have my vote for QOTW.

+1 as well
By the way, since we seem to be commenting on sigs in this thread,
"Codito ergo sum"
brings to mind one I love:

"Cogito ergo spud!" -- I think, therefore, yam!

(a U.S. Thanksgiving day coinage).

--Scott David Daniels
Sc***********@Acm.Org
Jul 18 '05 #43
Roy Smith wrote:
In article <33*************@individual.net>,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:
>+<< being an operator

Looks more like a smiley for "guy wearing a bowtie"

:)), I had a nice laugh with this one.

Jul 18 '05 #44
se******@spawar.navy.mil wrote:
I can't thank you enough for your reply and for everyones' great info
on this thread. The end of your email gave a rock solid reason why it
is impossible to improve upon ()'s for tuples....

Actually, you missed the point. The parentheses don't have anything to do with
the tuple. They are just used for disambiguation. It's the commas that define
the tuple.

--
Timo Virkkala
Jul 18 '05 #45

This thread has been closed and replies have been disabled. Please start a new discussion.