On Thu, Feb 26, 2015 at 7:45 AM, Mark Lawrence <breamore...@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. -- https://mail.python.org/mailman/listinfo/python-list