In article <52b782db$0$6599$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> Code that relies on side-effects is usually a sign of poor > design. I don't understand what you're trying to say there. A bit later in your post, you wrote: try: a() b() c() except SomeError: handle_error() Clearly, since the return values of a(), b(), and c() aren't saved, the only reason they're getting called is for their side effects. And I don't see anything wrong with that. BTW, there's a pattern we use a bunch in the Songza server code, which is sort of this, but in reverse. We'll have a bunch of possible ways to do something (strategies, to use the pattern vernacular), and want to try them all in order until we find one which works. So, for example: classes = [ClientDebugPicker, StatefulSongPicker, SWS_SequentialSongPicker, StandardSongPicker] for cls in classes: picker = cls.create(radio_session, station, artist) if picker: return picker else: assert 0, "can't create picker (classes = %s)" % classes 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". -- https://mail.python.org/mailman/listinfo/python-list