length of a tuple or a list containing only one element

[TP]

Hi everybody,

I have a question about the difference of behavior of "len" when applied on
tuples or on lists. I mean:

$ len( ( 'foo', 'bar' ) )
2
$ len( ( 'foo' ) )
3
$ len( [ 'foo', 'bar' ] )
2
$ len( [ 'foo' ] )
1

Why this behavior for the length computation of a tuple?
For my application, I prefer the behavior of length for a list. If I want to
store some values in a tuple because they should not be modified, the case
where the tuple contains only one element bothers me.

Thanks

Julien
--
python -c "print ''.join([chr(154 - ord(c)) for c in '*9(9&(18%.9&1+,\'Z
(55l4('])"

"When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong." (first law of AC Clarke)

 

[alex23]

I have a question about the difference of behavior of "len" when applied on
tuples or on lists. I mean:
$ len( ( 'foo' ) )
3

This is actually the length of a bracketed string, not a tuple.
Tuple's are defined by the existence of a comma...try:
1

 

[Tim Chase]

For making a literal tuple, parentheses are irrelevant; only the

commas matter:

I don't think I'd go so far as to say that the parentheses around
tuples are *irrelevant*...maybe just relevant in select contexts
... for i, arg in enumerate(args):
... print i, arg
... 0 1
1 2 0 (1, 2)

pedantically-grinning-ducktyping-and-running-ly yers,

-tkc

 

[bearophileHUGS]

TP:

This is actually the length of a bracketed string, not a tuple.
Tuple's are defined by the existence of a comma...try:
1

Time ago I have suggested to change the tuple literal, to avoid the
warts of the singleton and empty tuple, that may lead to bugs. But
using ASCII alone it's not easy to find something suitable and nice.

One of the suggestions of mine was to use (|...|) or [| x, ... |] to
denote tuples. This may lead to problems with the bitwise operators,
so the following two tuples:
t1 = ()
t2 = (x | y,)

Become (Fortress language uses similar liters, I think):
t1 = (||)
t2 = (| x OR y |)

Or this:
t1 = [||]
t2 = [| x OR y |]

Where OR, AND, XOR, NOT, SHL, SHR are the bitwise operators.
Having to type (| |) often is less handy, for example this code:

def divmod(a, b):
return a // b, a % b
d, r = divmod(10, 7)

becomes:

def divmod(a, b):
return (| a // b, a % b |)
(|d, r|) = divmod(10, 7)

Bye,
bearophile

 

[Steve Holden]

Where OR, AND, XOR, NOT, SHL, SHR are the bitwise operators.
Having to type (| |) often is less handy, for example this code:

Which is precisely why bare parentheses are used. And remember, you
often don't need to put the parentheses in. While this kind of beginner
mistake is common it isn't one that's frequently repeated once the
learner understands the syntax.

regards
Steve

 

[bearophileHUGS]

Steve Holden:

While this kind of beginner
mistake is common it isn't one that's frequently repeated once the
learner understands the syntax.

You may be right, but I don't have to like it.
When you teach programming to people that have never done it before,
and you use Python, they spot similar inconsistences in the blink of
an eye and often look annoyed. They want a clean language, so you have
to explain them the difference between a practical engineering system
(like Python/Scheme or on the opposite C++) and an abstract system
that you can use to reason (like some parts of mathematics they know).
The good thing is that Python3 fixes some of those things

Bye,
bearophile

 

[Arnaud Delobelle]

Steve Holden:

While this kind of beginner
mistake is common it isn't one that's frequently repeated once the
learner understands the syntax.

You may be right, but I don't have to like it.
When you teach programming to people that have never done it before,
and you use Python, they spot similar inconsistences in the blink of
an eye and often look annoyed. [...]

You can teach them that the comma is a terminator rather than a
separator (no more inconsistencies), but that the python parser is
forgiving and understands when the last comma is missing if the
expression is not already meaningful.

I.e. one should write

(1, 2, 3,)

But python, being nice, understands when you write

(1, 2, 3)

Now consider this:

3 * (1 + 2)

What interpretations should python take of the brackets?

The good thing is that Python3 fixes some of those things

And introduces some new inconsistencies for newcomers, e.g.

s = {1, 2, 3} # A set with 3 elements
s = {1} # A set with one element
s = {} # Surely, this should be an empty set!!

 

[bearophileHUGS]

Arnaud Delobelle:

And introduces some new inconsistencies for newcomers, e.g.
s = {1, 2, 3} # A set with 3 elements
s = {1} # A set with one element
s = {} # Surely, this should be an empty set!!

Are you able to list other inconsistencies?

Python3 introduces one or two warts, but removes many more
inconsistencies, so for me it's a net gain.

So far for me, beside the one you have shown, there's only another
detail I don't like of Python3 (the removal of tuple unpaking in
function calls).

Bye,
bearophile

 

[Tim Chase]

For making a literal tuple, parentheses are irrelevant; only the

I'll see your pedantry and raise you one:
0 ()

And just because another "tuples without parens" case exists:
File "<stdin>", line 1
foo(,)
^
SyntaxError: invalid syntax

To maintain the poker theme, I'd say "You raised, and I call" but
my call fails

-tkc

 

[Glenn Linderman]

And just because another "tuples without parens" case exists:

File "<stdin>", line 1
foo(,)
^
SyntaxError: invalid syntax

To maintain the poker theme, I'd say "You raised, and I call" but my
call fails

-tkc

I'm glad you guys had this thread, which I read with interest and some
amusement back when it happened. I am an experienced programmer, but a
relative newcomer to Python.

And so it was, the last couple nights, that I spent much time looking
for why my CherryPy configuration didn't work, and after much searching
of the CherryPy documentation for a tracing technique (which I still
wish I could find), I finally hacked the code to add an extra pprint.
Even after that, I focused on the wrong data in the pprint output.

At long last, I discovered that somehow my hash-of-hashes was mostly a
hash-of-hashes, but there was a tuple in there that contained a hash
too! Now how did that get in there?

conf['/path'] = {
'item1': 'value1',
'item2': 'value2',
},

So I was focusing on the items and values of the pprint, and they were
all correct. But this tuple clearly didn't belong, but my brain was
expecting that tuples would be surrounded by () in source...