On Mon, 2007-06-11 at 02:04 -0700, sandro dentella wrote: > I'm writing some tests for a project. I'd like to be able to decide if/ > when localization should > take place from within the test, but it seems I cannot overwrite > settings values (below is the traceback). > > I see that in tests/runtest.py it changes that value so I'm a little > puzzzled... > Should I be able to change it? > Is this the way to go? (i'm not really convinced...) > > sandro > *:-) > > In [2]: settings.LANGUAGE_CODE = 'en_en' > ERROR: Internal Python error in the inspect module. > Below is the traceback from this internal error.
Firstly, trying to do that works for me. So there's something else going wrong. Are you running under psyco or something? Try just using the Python shell and remove any influence ipython might be having on the situation. Secondly, I'm not quite sure what's happening there, but writing to settings is not encouraged. Note that runtest only adjust certain settings very, very early in the process, before they are used by anything. I'm not sure there's going to be a really neat solution here. The test framework is designed to test things based on a particular collection of settings in the settings file you pass to it. Changing that underlying set of assumptions (the settings) is not particularly stable, since it's not something Django supports in general. So one solution is to use two different settings files if you want to test two different LANGUAGE_CODE settings (your tests can read the value of the setting to work out the expected result). I'm not quite sure what you're trying to do, since I would have thought most of this can be tested using the HTTP language acceptance header with the LocaleMiddleware for client testing and activate()/deactivate() for unit tests. Note that using the HTTP headers causes the software to act in *exactly* the same way as setting LANGUAGE_CODE, because the HTTP header just overrides the default setting. So what can't be tested that way that needs LANGUAGE_CODE changed? Maybe there's another approach we can suggest. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
