On Mon, Dec 23, 2013 at 12:24 PM, Roy Smith <r...@panix.com> wrote: > Each SongPicker subclass encapsulates some logic for how to pick the > next song. It can also decide if the strategy it implements is > appropriate for the particular request; create() either returns an > instance of the class, or None. Returning None means, "I'm not the > right picker for this request; try the next one and see what he says".
But in that instance, the picker has done nothing. The main effect is to return a value, and since it returned None, you go on to do something else. This looks fine: foo = a() or b() or c() And it also looks like it would be safe to drop one of the calls if you know it won't succeed: if no_way_that_b_will_work: foo = a() or c() The point about side effects is that b() still has to be called, here, and the original statement doesn't make that clear. When you call a function and ignore its return value, you're clearly doing it for its side effects. Imagine this: width_required = max(len(foo),len(bar),len(quux)) Any sane reader is going to assume that the length checks aren't going to have side effects... but they could! Imagine if testing the length of something forced it to be loaded into memory, thus triggering any exception that would otherwise not be triggered until the thing got loaded much later. Vaguely plausible, but bad design because it's extremely unclear. ChrisA -- https://mail.python.org/mailman/listinfo/python-list