I was going to propose the same thing Santiago. Signals seem like the
ideal candidate to solve that problem.
--
David Cramer
http://www.davidcramer.net
On Fri, Nov 5, 2010 at 4:57 AM, Santiago Perez wrote:
>> * Settings that are internally cached. For example, anything that
>> modifies INSTALL
>
> * Settings that are internally cached. For example, anything that
> modifies INSTALLED_APPS.
>
> * Settings that need to make call to reset state affected by loading
> new new group of settings. For example, if you change TZ, you need to
> call "time.tzset()" on teardown to reset the timezone
On Nov 5, 2:18 am, Alex Gaynor wrote:
> def setUp(self):
> self.old_SETTING = getattr(settings, "SETING", _missing)
>
> def tearDown(self):
> if self.old_SETTING is _missing:
> del settings.SETTING"
> else:
> settings.SETTING = self.old_SETTING
How about introducing a n
On Fri, Nov 5, 2010 at 8:18 AM, Alex Gaynor wrote:
> On Thu, Nov 4, 2010 at 8:14 PM, Russell Keith-Magee
> wrote:
>> So - tl;dr. love the idea. However, we need to handle the edge cases
>> if it's going to be added to Django trunk, and replacing Django's own
>> usage of the ad-hoc pattern is as g
On Thu, Nov 4, 2010 at 8:14 PM, Russell Keith-Magee
wrote:
> On Fri, Nov 5, 2010 at 3:46 AM, David Cramer wrote:
>> A common behavior I seem to have is the need to tweak the settings
>> object for certain test cases. The other case is that in many cases we
>> were (are?) relying on settings being
On Fri, Nov 5, 2010 at 3:46 AM, David Cramer wrote:
> A common behavior I seem to have is the need to tweak the settings
> object for certain test cases. The other case is that in many cases we
> were (are?) relying on settings being configured a certain way for the
> Django tests to even work. I
On 4 November 2010 22:30, David Cramer wrote:
> Agree with Alex. We're considering moving more towards decorating
> views rather than class attributes. I'm not sure of the performance
> implications of many classes vs decorating functions on a large class
> instead, but it just seems to make more
Btw, not all settings can be patched just by overriding values because
some of them are cached and the change of the value doesn't change
django behaviour (e.g. TEMPLATE_CONTEXT_PROCESSORS option behaves like
this).
On 5 ноя, 02:23, Łukasz Rekucki wrote:
> Funny, I had exactly the same problem to
On Nov 4, 4:26 pm, Alex Gaynor wrote:
> 2010/11/4 Łukasz Rekucki :
>
>
>
>
>
> > Funny, I had exactly the same problem today at work while refactoring
> > my application's tests suite :).
>
> > Currently, I'm using a pair of save/restore functions: save() monkey
> > patches the settings module a
Agree with Alex. We're considering moving more towards decorating
views rather than class attributes. I'm not sure of the performance
implications of many classes vs decorating functions on a large class
instead, but it just seems to make more sense in some cases.
Here's a working (we're now using
2010/11/4 Łukasz Rekucki :
> Funny, I had exactly the same problem today at work while refactoring
> my application's tests suite :).
>
> Currently, I'm using a pair of save/restore functions: save() monkey
> patches the settings module and returns a dictionary of old values,
> restore() puts back
Funny, I had exactly the same problem today at work while refactoring
my application's tests suite :).
Currently, I'm using a pair of save/restore functions: save() monkey
patches the settings module and returns a dictionary of old values,
restore() puts back the old values based on the dictionary
With a decorator approach here's what I whipped up:
(This is dry code)
def with_settings(**overrides):
"""Allows you to define settings that are required for this
function to work"""
NotDefined = object()
def wrapped(func):
@wraps(func)
def _with_settings(*args, **kwar
> Let me start with an example test:
>
> def test_with_awesome_setting(self):
>_orig = getattr(settings, 'AWESOME', None)
>settings.AWESOME = True
>
># do my test
>...
>
>settings.AWESOME = _orig
>
Pedant: there's a small bug above which has bitten me before doing a simila
On Thu, Nov 4, 2010 at 3:46 PM, David Cramer wrote:
> A common behavior I seem to have is the need to tweak the settings
> object for certain test cases. The other case is that in many cases we
> were (are?) relying on settings being configured a certain way for the
> Django tests to even work. I
A common behavior I seem to have is the need to tweak the settings
object for certain test cases. The other case is that in many cases we
were (are?) relying on settings being configured a certain way for the
Django tests to even work. I brought this up in #django-dev a while
back, but wanted to op
16 matches
Mail list logo
