Tobiah: >From the standpoint of implementation, I don't see much of a difference unless you are specifically interested in the more limited functionality of a module (vs. a class instance). If you aren't, then you can simply instantiate your borg class and then insert it into sys.modules early in the pipeline; future imports of that module will get your instantiated class instead of the dummy module. Thus, you can use the import syntax yet still have descriptors and other class-based features.
I would carefully consider doing this, though. It would be a somewhat uncommon use of import mechanics, and a particularly confusing one at that since the developer has to understand how the module-like object is being used differently. The flexibility of the import mechanics is there so that we can make something other than a common module look like a common module; having it not act like a common module might be making the endeavor overly complex and obscure. For example, the Twisted framework uses this technique to allow global access to the installed reactor via import syntax, which works well within the framework. It did, however, throw me a bit when I first encountered it, and drove me to pour over the source to find out what was happening. Perhaps this was good, but I wonder if it would just have been simpler to provide the same access through a module function (eg: reactor.reactor() -> reactor instance). -- Jordan McCoy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tobiah Sent: Monday, July 31, 2006 2:52 PM To: python-list@python.org Subject: Borg vs. Module I am making a web app, made up of many modules that all need access to some important data, like the current session data, cookies, navigation history, post/get variables, etc. I decided to go with the 'Borg' idea, by assigning the __dict__ of an object to a class variable so that each instantiation of the Borg() would share the same data. That way I can either pass the Borg around, or just Borg() it if I need it in some obscure place. Then I read an argument that it usually makes more sense to just have a module with the data and functions that I need, which all the other modules can simply import. Since I only need one instance, I could just stuff data and call 'methods' on this module, probably without even changing existing syntax. Are there any arguments as to which method is better? Thanks, Toby -- Posted via a free Usenet account from http://www.teranews.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
