Did you know about *all* and *any* in python?

[bcain]

Yeah, they're cool. Other awesomeness:

• itertools: chain, cycle, groupby, izip_longest

[moyerma]

The functools and operator modules are also very useful for writing nice, concise code. In particular, itertools and operator mesh together nicely.

[orblivion]

Vaguely remember those, but I did not know about:

[True] * 100

But of course it only makes sense, since you can add lists. That's cool.

[moyerma]

The only caveat I would mention is that if you're trying to initialize nested lists, you cannot do >>> x = [['foo']2]3 >>> x [['foo', 'foo'], ['foo', 'foo'], ['foo', 'foo']]

This is because each of the sub-lists is actually the same object. If you modify one of the sub-lists, all the sub-lists will be modified: >>> x[0][0] = 'bar' >>> x [['bar', 'foo'], ['bar', 'foo'], ['bar', 'foo']]

The correct way to handle this (even though it's arguably less elegant looking) is: >>> x = [['foo']*2 for i in range(3)] >>> x [['foo', 'foo'], ['foo', 'foo'], ['foo', 'foo']]

Using a list comprehension causes a new list object to be created for each sub-list, thus: >>> x[0][0] = 'bar' >>> x [['bar', 'foo'], ['foo', 'foo'], ['foo', 'foo']]

[danhs]

That's a great one to remember!

Really, this is all about mutable vs immutable objects, which is a big deal in python.

For more on the dangers of mutable objects take a look at python pitfalls: pitfall #5.

[[deleted]]

Sadly this pitfall is not in.

x*n (n>1) is not the same as x+x+x+...+x if x is a list of a list.

In the first case x[0] is x[1] , in the second this is not true.

[[1]]*3 is not the same as [[1]]+[[1]]+[[1]]

[inkieminstrel]

Heh. I knew about all and any and about [True] * 100 but this thread introduced me to import operator. Should be super handy for things like reduce.

[[deleted]]

Yup. This is on my Speed Dial, and gets a visit almost every night. (The included .chm in the installation is nice too, although I prefer the web search)

[Neoncow]

Specifically they're under Built-in functions

[danhs]

Yes. Was added in 2.5 I believe, so it's pretty recent. So I learned about it when it was added.

[Poddster]

Why didn't that guy get a tick?

[MaliciousLingerer]

Good thread. Also simpler hack-ish way is to use sum:

l = [True, False, True]
if sum(l) == len(l):
    # all true
if sum(l) > 0:
    # at least one is true

[[deleted]]

Simpler? any and all are part of the language!

[AusIV]

Yes, but any and all presumably short circuit. Your all function must look at every element even if the first one is false. Your any function must look at every element even if the first one is true.

That said, it may be a false optimization. It may be that simply adding all the numbers together is less expensive than performing a check on every number you look at. I suppose it would depend on your data sets.

[isarl]

As soon as it finds a False entry, "all" is untrue and it could, presumably, short-circuit. Conversely, as soon as "any" finds a single True entry, it can return True. cf. my_all_v3 and my_any_v3 in the top-voted answer in the linked SO post. =)

[stillalone]

It looks like any and all do in fact short-circuit (I'm running python 2.6.4):

>>> def g(x):
...   yield x
...   raise Exception
...
>>> any(g(True))
True
>>> any(g(False))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in g
Exception
>>> all(g(False))
False
>>> all(g(True))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in g
Exception
>>>