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

[seberino]

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!

 

[Marius Bernklev]

* (e-mail address removed)

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

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

 

[Hans Nowak]

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.

(5,)

but:

(8, 9)

HTH,

 

[Leif K-Brooks]

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.

 

[Alex Martelli]

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

 

[Brian Beck]

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.

 

[Steve Holden]

* (e-mail address removed)




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

And, even there, the parenthesis is only required when it would
otherwise be embiguous:

regards
Steve

 

[John Roth]

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

 

[Grant Edwards]

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

Except they're not.

Tuples are defined by the infix comma "operator".

 

[Roy Smith]

Except they're not.


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

 

[John Roth]

Except they're not.



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

 

[Roy Smith]

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.

 

[Reinhold Birkenfeld]

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

 

[Grant Edwards]

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/vidlib/species/Uria_aalge.htm

 

[Rocco Moretti]

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.

 

[Reinhold Birkenfeld]

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

http://www.seabird.org/education/animals/guillemot.html
http://www.birdguides.com/html/vidlib/species/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

 

[Roy Smith]

[/QUOTE]

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

 

[Grant Edwards]

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.

 

[Dan Sommers]

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

 

[seberino]

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