Ad hoc lists vs ad hoc tuples

[Floris Bruynooghe]

One thing I ofter wonder is which is better when you just need a
throwaway sequence: a list or a tuple? E.g.:

if foo in ['some', 'random', 'strings']:
...
if [bool1, bool2, boo3].count(True) != 1:
...

(The last one only works with tuples since python 2.6)

Is a list or tuple better or more efficient in these situations?

Regards
Floris

PS: This is inspired by some of the space-efficiency comments from the
list.pop(0) discussion.

[Iain King]

On Jan 27, 10:20 am, Floris Bruynooghe <floris.bruynoo...@gmail.com>
wrote:

I tend to use tuples unless using a list makes it easier to read. For
example:

if foo in ('some', 'random', 'strings'):

draw.text((10,30), "WHICH IS WHITE", font=font)
draw.line([(70,25), (85,25), (105,45)])

I've no idea what the performance difference is; I've always assumed
it's negligible.

Iain

[M.-A. Lemburg]

Tuples are a faster to create than lists, so if you create
lots of them and don't need the list features, use tuples.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Jan 27 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/

[Steve Holden]

The fact that you have felt able to neglect the performance difference
makes it quite literally negligible.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

[Steve Holden]

[Antoine Pitrou]

Le Wed, 27 Jan 2010 02:20:53 -0800, Floris Bruynooghe a écrit :
>
> Is a list or tuple better or more efficient in these situations?

Tuples are faster to allocate (they are allocated in one single step) and
quite a bit smaller too.
In some situations, in Python 2.7 and 3.1, they can also be ignored by
the garbage collector, yielding faster collections.

(not to mention that they are hashable, which can be useful)

[Terry Reedy]

On 1/27/2010 12:32 PM, Antoine Pitrou wrote:
> Le Wed, 27 Jan 2010 02:20:53 -0800, Floris Bruynooghe a écrit :
>>

>> Is a list or tuple better or more efficient in these situations?
>

> Tuples are faster to allocate (they are allocated in one single step) and
> quite a bit smaller too.
> In some situations, in Python 2.7 and 3.1, they can also be ignored by
> the garbage collector, yielding faster collections.
>
> (not to mention that they are hashable, which can be useful)

Constant tuples (a tuple whose members are all seen as constants by the
compiler) are now pre-compiled and constructed once and put into the
code object as such rather than re-constructed with each run of the code.

>>> from dis import dis
>>> def l(): return [1,2,3]

>>> def t(): return 1,2,3

>>> dis(l)
1 0 LOAD_CONST 1 (1)
3 LOAD_CONST 2 (2)
6 LOAD_CONST 3 (3)
9 BUILD_LIST 3
12 RETURN_VALUE
>>> dis(t)
1 0 LOAD_CONST 4 ((1, 2, 3))
3 RETURN_VALUE
>>> # 3.1

Terry Jan Reedy

[Floris Bruynooghe]

On Jan 27, 10:15 pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 1/27/2010 12:32 PM, Antoine Pitrou wrote:
>
> > Le Wed, 27 Jan 2010 02:20:53 -0800, Floris Bruynooghe a écrit :
>
> >> Is a list or tuple better or more efficient in these situations?
>
> > Tuples are faster to allocate (they are allocated in one single step) and
> > quite a bit smaller too.

Thanks for all the answers! This is what I was expecting but it's
nice to see it confirmed.

Regards
Floris

[Duncan Booth]

Terry Reedy <tjr...@udel.edu> wrote:

> Constant tuples (a tuple whose members are all seen as constants by the
> compiler) are now pre-compiled and constructed once and put into the
> code object as such rather than re-constructed with each run of the code.

Sadly that's not entirely accurate.

Tuples whose members are all simple constants are pre-compiled, but here's
an example of a tuple whose members are all constants but doesn't get
optimised:

>>> def foo():
data = (
('hello', 42),
('world', 24),
)
return data

>>> import dis
>>> dis.dis(foo)
3 0 LOAD_CONST 5 (('hello', 42))

4 3 LOAD_CONST 6 (('world', 24))
6 BUILD_TUPLE 2
9 STORE_FAST 0 (data)

6 12 LOAD_FAST 0 (data)
15 RETURN_VALUE

--
Duncan Booth http://kupuguy.blogspot.com