meridian a écrit : > Bruno Desthuilliers wrote: > >>meridian wrote: >> >>>Bruno Desthuilliers wrote: >>> >>> >>>>def doIt(name=None): >>>> global gname >>>> if name is None: >>>> name = gname >>>> else: >>>> gname = name >>>> >>> >>> >>>Thanks Bruno, works a treat... >>> >> >>But still very probably a bad idea. >> > > Ok, my curiosity is pique'd - is there a better way to hold my > app/module globals?
Probably !-) Now which one depends on your app design and execution model... > I must say I'd prefer not to write global <var> in every function, for > every global var I need. > Maybe there's a simpler way to structure?... by a global class or > something? <ot>What is a "global class" ?</ot> The problem with "app globals" is that they introduce too much coupling (you end up having all your code depending on the globals). So the first thing to do is identify who really needs to know what, and who is responsible for knowing what. Anyway, most globals should be configuration stuff - so usually read only. There are very good reasons to avoid modifying globals in functions, and specially when it comes to web programming where you have to handle concurrent access (which is why I insist on telling you that what you want to do may be very dangerous). Usually one uses a variant of the MVC, which helps separating concerns : the model is about data (structure and persistance), the view(s) about outputs (display data), and the controler about inputs (processing the request). The flow is something like: controller parses request, takes any appropriate action, selects appropriate elements from the model, feed'em to appropriate view, and returns the result of view execution as a response (general scheme, depends on whether it's plain cgi, mod_python, fastcgi, wsgi, standalone server or whatnot). It's clear that the controler needs some knowldge about the model and the views, that the views are tightly coupled to the model but don't need to know about the controller, and that the model just don't give a damn about both controller and views. So we have: controller -> depends on model and view view -> depends on model model -> depends on nobody Since handling a request is the controller's duty, the model should not know about the request. The only 'global' things the model has to know are related to data access configuration (db connection string, physical path to resources on the filesystem etc...). Since the model is called by the controller, it's the controller's job to pass these informations to the model when appropriate. Views may also need to access app-wide settings like urls to resources, localisation stuff etc. Here again, since views are invoked by the controller, it's usually the controller that is responsible for passing relevant knowledge to the views - either directly (raw data) or indirectly (thru some helper objects that holds the required knowledge and are called by the view code). As you can see, you've already eliminated any needs for globals in both the views and the model (view or model specific module-level pseudo-constants set aside, but then it's mostly safe). I don't know which web solution you use, but I strongly suggest that you take some time studying existing web applications or frameworks like Trac, Django, CherryPy etc. HTH -- http://mail.python.org/mailman/listinfo/python-list
