Re: Accidental logging disabling
On 04/18/2011 08:25 AM, Carl Meyer wrote: FWIW, I don't think changing settings in general to be non-lazy is an option - it will suddenly make a bunch of parts of Django dependent on DJANGO_SETTINGS_MODULE at import time, where currently they only require it at runtime (and even then perhaps only when certain functionality is used). I do, however, think that it would be fine to have the setup_environ function explicitly trigger settings-loading. This should never be a problem, because setup_environ already sets DJANGO_SETTINGS_MODULE. It's also not an invasive change at all - it should be a one-liner, I think. After some thinking I agree with you. That might be reasonable as well - I'm interested to hear Russell speak to that Ditto. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Accidental logging disabling
Hi Ivan, On 04/17/2011 10:38 PM, Ivan Sagalaev wrote: > On 04/15/2011 02:20 AM, akaariai wrote: >> I have been using setup_environ in my projects, and the lazy >> initialization in can cause some weird problems, for example if you do >> manual timing using: >> start = datetime.now() >> access settings >> print 'Used %s' % (datetime.now() - start) >> >> You might get weird results as accessing settings can change your >> timezone. Would it be wise that setup_environ() would access the >> settings so that they are no more lazy? Or does this cause other >> problems? > > I didn't have in mind changing the settings object to be non-lazy. It > looks like a rather intrusive change. And I can't really predict > consequences. FWIW, I don't think changing settings in general to be non-lazy is an option - it will suddenly make a bunch of parts of Django dependent on DJANGO_SETTINGS_MODULE at import time, where currently they only require it at runtime (and even then perhaps only when certain functionality is used). I do, however, think that it would be fine to have the setup_environ function explicitly trigger settings-loading. This should never be a problem, because setup_environ already sets DJANGO_SETTINGS_MODULE. It's also not an invasive change at all - it should be a one-liner, I think. My gut feeling tells me that changing things from being > immediate to be lazy is the source of many hidden problems. But it > should be safe vice versa because if the environment already works with > a lazy object it couldn't count on the order of execution. So immediate > instantiation shouldn't break the logic. What it could do though is > affect performance… I don't think there would be any performance issues. Any code that's calling setup_environ is quite likely accessing settings not long thereafter, so it would shift a rather small bit of work that would happen anyway to happen sooner rather than later. > Anyway I still think strongly suggesting not disabling existing loggers > would suffice. That might be reasonable as well - I'm interested to hear Russell speak to that, as he did the logging work. I still think making setup_environ non-lazy is a reasonable change that will address a broader range of problems. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Accidental logging disabling
On 04/15/2011 02:20 AM, akaariai wrote: I have been using setup_environ in my projects, and the lazy initialization in can cause some weird problems, for example if you do manual timing using: start = datetime.now() access settings print 'Used %s' % (datetime.now() - start) You might get weird results as accessing settings can change your timezone. Would it be wise that setup_environ() would access the settings so that they are no more lazy? Or does this cause other problems? I didn't have in mind changing the settings object to be non-lazy. It looks like a rather intrusive change. And I can't really predict consequences. My gut feeling tells me that changing things from being immediate to be lazy is the source of many hidden problems. But it should be safe vice versa because if the environment already works with a lazy object it couldn't count on the order of execution. So immediate instantiation shouldn't break the logic. What it could do though is affect performance… Anyway I still think strongly suggesting not disabling existing loggers would suffice. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Accidental logging disabling
On 04/15/2011 04:20 AM, akaariai wrote: > I have been using setup_environ in my projects, and the lazy > initialization in can cause some weird problems, for example if you do > manual timing using: > start = datetime.now() > access settings > print 'Used %s' % (datetime.now() - start) > > You might get weird results as accessing settings can change your > timezone. Would it be wise that setup_environ() would access the > settings so that they are no more lazy? Or does this cause other > problems? I think this would be worth experimenting with. AFAIK the only real reason for settings to be lazy is to avoid the dreaded "Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined." when importing modules that import settings (instead you only get it when settings are actually accessed). But that's not an issue for setup_environ, because it takes the module as parameter and actually sets DJANGO_SETTINGS_MODULE. So I don't think there would be any harm (and there would be significant predictability benefit) in having setup_environ trigger the actual loading of settings immediately. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Accidental logging disabling
On Apr 15, 7:34 am, Ivan Sagalaev wrote:
> import logging
>
> import settings
> from django.core.management import setup_environ
> setup_environ(settings)
>
> from django.test.client import RequestFactory
>
> factory = RequestFactory()
> factory.get('/')
> logger = logging.getLogger('django.request')
> logger.error('Error')
>
> The message doesn't show up in the console. Here's what's happening here:
>
> 1. setup_environ creates a lazy setting object
>
> 2. importing RequestFactory triggers import of django.core.handlers.wsgi
> that creates a logger 'django.request'
>
> 3. after some time settings object is accessed for the first time and
> gets initialized
I have been using setup_environ in my projects, and the lazy
initialization in can cause some weird problems, for example if you do
manual timing using:
start = datetime.now()
access settings
print 'Used %s' % (datetime.now() - start)
You might get weird results as accessing settings can change your
timezone. Would it be wise that setup_environ() would access the
settings so that they are no more lazy? Or does this cause other
problems?
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Accidental logging disabling
Hello everyone!
I've found a (may be minor) bug with logging and I'm not sure how it can
be fixed. Here's a stripped-down example showing the problem:
The settings.py simply configures a single root logger:
DEBUG = True
DATABASES = {
'default': {
'engine': 'django.db.backends.sqlite3', 'name': ':memory:',
},
}
LOGGING = {
'version': 1,
'handlers': {
'default': {'class': 'logging.StreamHandler'},
},
'loggers': {
'': {'handlers': ['default']},
},
}
Then there's a script that initializes settings, does some tests and
tries to log a message into the 'django.request' logger:
import logging
import settings
from django.core.management import setup_environ
setup_environ(settings)
from django.test.client import RequestFactory
factory = RequestFactory()
factory.get('/')
logger = logging.getLogger('django.request')
logger.error('Error')
The message doesn't show up in the console. Here's what's happening here:
1. setup_environ creates a lazy setting object
2. importing RequestFactory triggers import of django.core.handlers.wsgi
that creates a logger 'django.request'
3. after some time settings object is accessed for the first time and
gets initialized
4. while initializing logging dictConfig disables all existing loggers
including 'django.request'
5. messages being sent into a disabled logger are ignored (even though
there is an enabled root logger)
In my opinion the main problem here is that dictConfig disables existing
loggers *by default*. A logger is nothing more than a declaration of a
name under which a particular set of messages can be distinguished, it
doesn't bear any actual functionality. Disabling it basically means that
we disable logging altogether for whoever happened to declare it
earlier. I suspect there are cases where it might be useful but doing it
by default doesn't make sense to me.
However this is not what Django is in a position to fix because it's
what Python's now-standard logging does. What we could fix though is the
example in the logging documentation:
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
...
Explicitly setting 'disable_existing_loggers' to True suggests that its
default value is False and just omitting this line would leave existing
loggers enabled. I think that at the very least we should change this
attribute to False and note that it should be done like that due to
Django's lazy setting initialization.
But in fact I'm not sure what to do here. May be even leave it as it is
because the bug doesn't manifest itself in common scenarios… Thoughts?
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
