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]

On Nov 3, 9:08*pm, TP <Tribulati...@P aralleles.inval idwrote:

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:

>>len(('foo', ))

1

[Ben Finney]

TP <Tr**********@P aralleles.inval idwrites:

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

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

>>type( ('foo', 'bar') )

<type 'tuple'>

>>type( ('foo',) )

<type 'tuple'>

>>type( ('foo') )

<type 'str'>

However, for making a literal list, the brackets do matter:

>>type( ['foo', 'bar'] )

<type 'list'>

>>type( ['foo',] )

<type 'list'>

>>type( ['foo'] )

<type 'list'>

--
\ “The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything.� —Aahz |
_o__) |
Ben Finney

[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

>>def foo(*args):

... for i, arg in enumerate(args) :
... print i, arg
...

>>foo(1,2)

0 1
1 2

>>foo((1,2)) # these parens are pretty important :)

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:

>len(('foo',) )

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]

be************@ lycos.com wrote:
[...]

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
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[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

[Scott David Daniels]

Tim Chase wrote:

>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

>>def foo(*args):

... for i, arg in enumerate(args) :
... print i, arg
...

>>foo(1,2)

0 1
1 2

>>foo((1,2)) # these parens are pretty important :)

0 (1, 2)

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

I'll see your pedantry and raise you one:

>>foo()
foo(())

0 ()
--Scott David Daniels
Sc***********@A cm.Org

[Arnaud Delobelle]

be************@ lycos.com writes:

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!!

--
Arnaud

--
Arnaud

[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