Excellent suggestions, thanks!
The globals are not my cup of tea so my feet are currently safe from
that Django pattern. :) I do care about testing and have written unit
tests (although the code I need this in is currently not covered by the
tests), but just to understand the issue at hand, what can go wrong if I
only read the setting like in your get_setting def example?
I know about thread safety and writing shared data, and I know from C
that even reading data which is in the middle of a write by another
thread can produce corrupt results (especially with nonatomic data
types). Is that the case even in Python? The settings I need to read are
some custom config values that never change in the life of the
application (and I say this fully aware of the fact that almost
everything in Python is a reference, especially when dealing with lists
and dictionaries which can be changed "accidentally").
Basically my problem is only that of the separation of concerns. I have
a database model that logs certain operational stuff (not python logger)
and I want it to mail the error entries to the admin, so I want it
"agnostic" to the request chain and views used, because it can be called
in views, or command line scripts (using pyramid.paster.bootstrap),
etc... It requires admin address and smpt server data given in the
config files.
Thanks!
.oO V Oo.
On 12/01/2011 05:42 PM, Chris McDonough wrote:
On Thu, 2011-12-01 at 17:30 +0100, Vlad K. wrote:
Hello all!
What is the recommended way to fetch registry (settings) for read only
outside of the view (where request object is not available)? I was
looking at the threadlocal.get_current_registry() but the docs say it
should not be used except maybe in unit tests.
I understand that the request object should be passed around, but what
are my options if I want to avoid that?
To avoid passing deployment settings values around, your options are:
- Use get_current_registry()
- Use a pattern like
http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/configuration.html#django-style-settings-py-configuration
You're encouraged to pass per-request values around to make writing unit
tests pleasant and to make it possible to use more than one Pyramid app
per process. But...
If you don't care about testing but you do care about being able to run
more than one instance of the application in the same process:
def get_setting(setting_name, default=None):
return get_current_registry().settings.get('a', default)
def somefunction(a, b):
beinghosed = get_setting('i-am-hosing-myself')
If you care neither about testing nor about being able to run more than
one Pyramid application per process, the "django-style settings"
cookbook entry linked above puts the gun in your hands; it's pre-pointed
at your feet.
- C
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
