Python Worst Practices

[Chris Angelico]

On Thu, Feb 26, 2015 at 7:45 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> http://www.slideshare.net/pydanny/python-worst-practices
>
> Any that should be added to this list?  Any that be removed as not that bad?

Remove the complaint about id. It's an extremely useful variable name,
and you hardly ever need the function. The only reason to avoid it is
so you get an immediate NameError if you haven't assigned to id, and
the alternative is pretty easily debuggable. I agree that "zip" can
easily be replaced with "zip_code" or "postal_code"; the need to avoid
"object" is almost completely unnecessary for me as I'd always
abbreviate it to "obj" anyway, but it doesn't hurt to say it.

(Flipping the booleans makes no sense to me. When would 0 mean true
and 1 mean false? Isn't it much more likely that, for instance, 0
means success and nonzero means error (and maybe there's just one
error state, so 1 means failure)?)

I'd take the one about properties a bit further. Try to avoid using
settable properties *at all*, until you've proven that you absolutely
do need them. Just let the calling code directly mutate your
attributes!

I'd also strengthen the point about "except: pass". He says "Arguably
better to not have this in your code". I don't think there's any
"arguably" about it - silently swallowing *any* exception is just
wrong. (Incidentally, the advent of chained exceptions may mean that
some of the code can be simplified - no need to explicitly retain the
previous exception when raising a custom one.)

But I take issue with the general ban on lambda. He's showing an
atrocious use of lambda:

1) Assigning a lambda function to a simple name is pointless. If
you're not making use of the fact that lambda is an expression, use
def.
2) If you need to fiddle around with dunder methods to do what you
want, then you definitely shouldn't be doing this as a lambda
function. You're fighting against the language by wrapping your logic
up until it can be an expression, only to ignore the value of that
expression.
3) And if you need a nested function call to implement a local
variable, because your dunder method calling is getting ridiculously
long, then duh, use def!

I could come up with an equally atrocious mis-use of list
comprehensions. Does that mean that a list comp is "Python worst
practice", and we should unroll them all into assignment, loop,
append? No. Certainly not. [1] It just proves that the feature can be
misused.

Hah. Talking about old-style classes. Okay, here's another Python best
practice: Use Python 3 if you can. :) But if you can't, then I
definitely agree that you should subclass object, put parens around
your print arguments, use "as" when capturing exceptions, all those
little things that will make your code that bit more 2/3 compatible
without making it any worse Py2 code.

Additional Python worst practice, although I don't see it all that
often: Creating classes for anything and everything. In a lot of
cases, Python code works just fine at top-level (eg module-level
functions), and those levels of indirection don't make the code any
easier to read.

ChrisA

[1] Sooooooo..... Off we go to the Gaiety, for that's the place for me! [2]
[2] But you probably don't know that song, and I can't find it on
Youtube. "Johnny at the Gaiety", by George Grossmith, back in the late
19th century.