On Sun, Apr 24, 2016, 1:51 AM Steven D'Aprano <st...@pearwood.info> wrote:
> On Sun, 24 Apr 2016 12:34 pm, Michael Torrie wrote: > > > There are many aspects to Pythonic programming, not just OOP. For > > example using modules to store shared state for your program components > > is very pythonic, rather than using classes. A module is kind of like a > > singleton instance, and still is object-oriented by the way (the module > > is an object). > > I find myself going backwards and forwards on whether or not that is a good > idea. I think it depends on whether you are writing a library or an > application. > > If you're writing an application, then storing state in module-level > variables works fine. Your application is, effectively, a singleton, and if > you try to run it twice, you'll (probably) be running it in two distinct > processes, so that's okay. > > (If you're not, if somehow you perform some sort of trickery where you have > a single Python interpreter running your script twice in the same process, > then it will break horribly. But if you can do that, you're living on the > edge already and can probably deal with it.) > > But if you're writing a library, then using module state is a Bad Idea. > Your > library may be used by more than one client in the same process, and they > will conflict over each other's library-level state. "Global variables > considered harmful." > I think we're giving mixed messages because we're conflating "constants" and globals that are expected to change. In our case here, I think two clients in the same process sharing state might be a feature rather than a bug. Or at least it has the same behavior as the current implementation. > -- https://mail.python.org/mailman/listinfo/python-list
