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
available as a github branch; the compare view [2] presents it nicely
as a diff with
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, I'd take the
opposite expectation and assume that any filter / tag u
Hi all,
Just a quick note to say that on Trac you can use backticks to mark
inline code fragments instead of curly braces e.g.
Doing `from foo import *` is bad.
instead of
Doing {{{from foo import *}}} is bad.
The former is easier to type, and it is *much* easier to read the plain
text, es
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 Thu, 2010-11-04 at 17:24 +0100, Will Hardy wrote:
> I've attached a simple patch to the ticket [2] and would be happy to
> write tests and documentation if this approach is enough to overcome
> the "wontfix". Have I overlooked something?
I think the devil is in the details. If we go for a simp
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
Hi Will,
I've reopened the ticket, because that's elegant enough for me.
I remember having this discussion in IRC either with you or someone
else a while back and couldn't come up with any negatives to providing
this, as long as obvious caveats of tags/filters potentially relying
on the original
On Nov 4, 3:06 am, Jannis Leidel wrote:
> Ok, thanks for your input, would you mind creating a ticket describing the
> discrepancy in more detail? I thought the how to [1] explains enough of
> purpose of the app, so any further input would be much appreciated.
>
> > I'd be glad to help, but I'm
Hi all,
While using templates to produce something other than HTML (latex by
the way), I wanted to use my own escape function, instead of the
HTML-oriented default in autoescape.
This is of course not too difficult with filters and turning of
autoescape, but it would be very nice if I could get t
+1 for {% include "foo.html" x=1 y=2 %}
This just seems more natural. My designer agreed based on the {% url
%} tags.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
On 04.11.2010, at 00:55, Brian Neal wrote:
> On Nov 3, 4:12 am, Jannis Leidel wrote:
>>
>> No, MEDIA_* and STATICFILES_* settings aren't the same, the former is for
>> user generated content (like file uploads), the latter for general static
>> files your site needs to work (such as css/js fil
22 matches
Mail list logo
