Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 6:51 pm, Gabriel Hurley wrote: > 1. Add the versionadded directive to "docs/topics/db/queries.txt", and > "docs/ref/contrib/contenttypes.txt". For reference, you can make it > very clear what was changed/added by using the following syntax (note > the *single* line

Re: Call for review and comment: #7539 (ForeignKey on_delete)

> Another documentation-related question I have; is it necessary to mark > each passing referencing (and link) to on_delete with the version- > added marker? I went back and forth, and eventually decided against > it, for these reasons: (1) The passing references don't provide enough > info to use

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 11:17 am, Russell Keith-Magee wrote: > Giving credit where it's due, I think Michael Glassford also deserves > a shoutout here. He was the original driving force behind this ticket, > as was actively involved during the 1.2 development cycle. Indeed! My

Re: Changing settings per test

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

Re: Class-based views

Actually, I've already added your function into my django_future.py ;-) Thank you! I wasn't sure it's good with inheritance - good to hear that! But I wanted to know "the right way" in Django, and since your patch isn't in trunk yet, I didn't want to rely on it. If using both mixins and decorators

Re: Class-based views

2010/11/6 Łukasz Rekucki : > On 5 November 2010 16:52, Valentin Golev wrote: >> I'm sorry, I misread it. >> Please mention form.instance field in "forms for models" docs somewhere. >> >> The gain is inheritance. If one of your view classes is intented to

Re: Class-based views

On 5 November 2010 16:52, Valentin Golev wrote: > I'm sorry, I misread it. > Please mention form.instance field in "forms for models" docs somewhere. > > The gain is inheritance. If one of your view classes is intented to be > subclassed and requires logging in, Mixins are

Re: custom function for autoescape

On Thu, 2010-11-04 at 19:06 -0700, SmileyChris wrote: > Thanks for following up, Luke. > > I understand your point of view, but personally, I'm fine with an "all > bets are off using built-in filters/tags" clause on a custom escape > method. > While you'd expect that addslashes would just work,

Re: Class-based views

I'm sorry, I misread it. Please mention form.instance field in "forms for models" docs somewhere. The gain is inheritance. If one of your view classes is intented to be subclassed and requires logging in, Mixins are natural solution, methinks -- Best Regards, Valentin Golev Lead Developer r00,

Re: Class-based views

On Fri, Nov 5, 2010 at 11:40 PM, Valentin Golev wrote: > Are you certain about self.instance? > http://code.djangoproject.com/browser/django/trunk/django/views/generic/edit.py Lines > 173 and 90 tell me another thing... I didn't say self.instance. I said *form*.instance. >

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Fri, Nov 5, 2010 at 1:27 AM, Carl Meyer wrote: > Hi all, > > The patch for #7539 [1] (support for on_delete behaviors other than > cascading deletes) has reached a state where I consider it a candidate > for committing; I invite review and comments. The current patch is

Class-based views

Hello, I'm still playing with brand new class-based views. I think I'm not wrong about writing my experiences, questions and ideas so you developers could polish the API more (if I'm being useless here, sorry). My first question is, that is "the right way" to handle creation of objects with

Re: custom function for autoescape

Thanks for the explanation and perfect example Luke. I thought I would try to be helpful and went through the source code for all the filters and categorised them (see below). There are 12 filters that can't be used (8 are for html only anyway), 24 filters may fail unpredictably (like your

Re: Changing settings per test

> > * 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

Re: Changing settings per test

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