On Tue, 2012-01-31 at 12:30 +0100, Tom Lazar wrote: > On 31.01.2012, at 05:48, Chris McDonough wrote: > > > I think it might be significantly better to just create a settings.py > > module in your app and put stuff in there instead of in your config file > > hm, i don't want to *maintain* the settings in python code, just have easy > access. or else i end up with duplicate entries that i need to keep in sync.
You'd just do the work at global scope in a module to read them from an ini file. You wouldn't maintain them twice. > > if you want globals, because this is effectively a monkeypatch, and > > makes bootstrap code very timing-dependent. > > right. > > > Or you could do something > > like what's suggested in > > <http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/configuration.html#django-style-settings-py-configuration> > > wow, that approach seems almost ridiculous :) following it you end up with > having to pass in/configure the location of the ini file *twice* and parse > the whole thing manually *again*. i don't think i'll go down that road. If you did what that thing suggested you'd likely write a small wrapper to run your app instead of using paster serve, so there'd be no "twice". Or at least you can arrange to do that with enough imagination. > > I personally find that global settings makes my test code much more > > brittle, because it means I have to clean up the settings after changing > > them within test code instead of just saying "request.settings = {}". But > > at the end of the day, it's really up to you. > > ah, i just give each test a new instance of the settings, so there's no need > to clean up. > > i really would like to have a clean, convenient and supported way to access > global settings. i guess, the answer is that pyramid currently doesn't have > this on offer. No, it doesn't, or at least it leaves it up to you. Individuals can always make nonglobal things global, but a framework can't make things nonglobal once it makes them global. > generically exposing the settings that were used to invoke a pyramid instance > on module level would be nice, but i infer from what you've said the the > convenience that would add would be outweighed by the stuff that could > possibly go wrong. correct? The Django core devs I've heard always lament using global settings. The zope.testing.setUp stuff that clears a module scope registry is another antipattern. > maybe i could just mock get_current_registry() in my test harness and simply > use that in the few places of my code that does not have convenient access to > a request. I dunno. If you want global stuff it's easy enough to make things global if you use a little thought. Or just pass the request around. - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
