News for hackers. Stuff that matters.
Re:Python best practices by attack on Tuesday July 08, 2008 @07:04PM (#240488)
My comments:

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

     #!/usr/bin/env python
     # -*- coding: UTF-8 -*-
Re:Python best practices by aston on Tuesday July 08, 2008 @08:07PM (#240557)
Though I am a lowly Python noob, I'll tell you it's generally very bad practice to use a mutable as a default argument value. The reason is that a function's default is only ever initialized once. Case in point:

  >>> 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.
Re:Python best practices by nostrademons on Wednesday July 09, 2008 @11:37AM (#241262)
I always took that as a case against mutating arguments, not against defaults. You still have the same problem if you pass in an argument:

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

Re:Python best practices by BrandonM on Tuesday July 08, 2008 @10:06PM (#240649)
> class fooclass: ... || class Fooclass(object): ...

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.

Re:Python best practices by Erwin on Wednesday July 09, 2008 @05:01AM (#240938)
More importantly property getters will silently do nothing in old-style classes and just let the attribute setting through without calling the setter, while getters work fine.
Re:Python best practices by DocSavage on Tuesday July 08, 2008 @08:32PM (#240576)
> Extraneous spaces annoy me to end.

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/

Re:Python best practices by attack on Tuesday July 08, 2008 @08:59PM (#240596)
And look how complicated they make it. Sometimes spaces, sometimes not, how confusing. And tell me that their "Use spaces around arithmetic operators" example doesn't make you want to puke:

          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.
Re:Python best practices by BrandonM on Tuesday July 08, 2008 @10:04PM (#240644)
I do. I think it looks a lot better and more clear. It certainly looks a lot like what I would write down on paper, and that is one of the inherent qualities of Python in general.
Re:Python best practices by BrandonM on Wednesday July 09, 2008 @03:15AM (#240883)
The one place that I don't follow the guideline (unless it's the guideline and I just don't know it... it rarely comes up, so I haven't bothered to check) is on array indices. I do write:

  a[i+1]
Re:Python best practices by albertcardona on Wednesday July 09, 2008 @12:16PM (#241312)
Same here. I conceptualize it as part of a code compactness strategy: array indices are part of the same item, and thus I use syntax (like yours) that suggests inlining.
Re:Python best practices by bkovitz on Wednesday July 09, 2008 @03:15PM (#241543)
Same here, for the same reason.
Re:Python best practices by bkovitz on Wednesday July 09, 2008 @11:46AM (#241276)
I do. I find that code with the spaces around assignment and arithmetic operators is way easier to read.
Re:Python best practices by thorax on Wednesday July 09, 2008 @02:04AM (#240839)
I do all of these (even in interactive shell) except I have a weak spot for this sort of notation:

    i+=2
Re:Python best practices by pmorici on Tuesday July 08, 2008 @07:11PM (#240494)
I think he was saying use the curly braces instead of the dict() constructor.