>>> def f(l=[]):
... l.append(0)
... print l
...
>>> f()
[0]
>>> f()
[0, 0]
>>> f()
[0, 0, 0]
Unless you 1) actually want the appearance of a 'static' local variable or 2) are really careful to make a copy of the mutable before messing around with it, you'll get yourself into trouble.>>> MY_CONSTANT = ['foo', 'bar', 'baz'] >>> def f(l): ... l.append(0) ... print l ... >>> f() ['foo', 'bar', 'baz', 0] >>> f() ['foo', 'bar', 'baz', 0, 0]
I would've rewritten f as:
def f(l=[]):
print l + [0]
...unless you specifically want f to mutate its caller's variables and have documented it as such.Generally, I try to avoid mutating objects unless a.) I just created the object within the function or b.) it's specifically intended as a "long lived" data structure, i.e. something that survives multiple user interactions. For everything else, I try to use the non-mutating operations (slicing, concatenation, list comprehensions) or make an explicit copy of the argument.
Is this a joke?
No... it is generally recommended that class names are capitalized, and any classes you create are supposed to inherit from object. This mainly comes into effect when using super().
In Python 3K, I'm pretty sure that all classes will inherit from object without having to explicitly say it.
It is recommended in the "official" python style guide to surround the assignment operator with a single space: http://www.python.org/dev/peps/pep-0008/
i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)
Who writes like that?? I very strongly disagree.The authors of:
BitTorrent: https://develop.participatoryculture.org/trac/democracy/brow...
Django: http://code.djangoproject.com/browser/django/trunk/django/ut...
Pylons: http://pylonshq.com/project/pylonshq/browser/pylons/util.py
Twisted: http://twistedmatrix.com/trac/browser/trunk/twisted/python/u...
a[i+1] i+=2
> x=5 || x = 5
Noooo. That first one is backwards. Extraneous spaces annoy me to no end. Makes it a pain to search for things too.
On the other hand, using newlines to break things up at commas for example, is great. But that's not applicable here.
> class fooclass: ... || class Fooclass(object): ...
Is this a joke?
> d = dict() || frequences = {}
How can you say that longer names are always better? (Is that part of the message here?) Usually most variables are throw-away so using short names should be the most common case. Similar to mathematics.
> # Use iter* methods when possible
This should mention that thread-safety is probably the most directly relevant use case for the non-iterable methods.
> # coding: latin
Better to use this: