fwiw: when I started using pyramid I was also reluctant to pass around the request all the time. But it turned out to be the right (and transparent) thing to do. In my case this is because I often need request-specific information like the locale name basically everywhere. Once you get used to this (and to creating DummyRequests all the time for tests), you will come to like the registry as the place to go for global settings. regards robert
On Tue, Jan 31, 2012 at 12:30 PM, Tom Lazar <t...@pyfidelity.com> 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. > >> 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. > >> 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. > > 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? > > 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. > > sorry for rambling, i guess, i'm (ab-)using the list for rubberducking... :) > > tom > >> >> - 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. >> > > -- > 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. > -- 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.
