On Sep 10, 2013, at 7:05 PM, Russell Keith-Magee
wrote:
> I share James' reservations about this as a feature -- attaching flags to
> Meta is something I can see being abused in all sorts of ways -- but that
> doesn't mean there's no legitimate uses for extensions to
On Jul 14, 2012, at 6:37 PM, Russell Keith-Magee wrote:
>
> My only concern is:
>
>> We could store which fields have these hooks upon ModelBase.__new__
>> construction and so skip most fields and overhead in __init__.
>
> I'm not sure if I'm misreading your intentions here, but just to be
>
lates "leads terrible looking URL", it's really true.
>
> If you don't think you agree with me in all, please tell me. Because as my
> english is not very good I don't know if I have understand you perfect.
>
> --
> Pablo Martín
>
> 2010/10/15 Andy McCurdy <sed...@
2010/10/15 Łukasz Rekucki
> 2010/10/15 J. Pablo Martín Cobos :
> >
> > Really the problem comes when we reuse a application: from other people,
> > from Django (i.e. django.contrib.admin), or even my own that we reuse in
> > some projects. Usually you want
On Fri, Oct 15, 2010 at 6:09 AM, Andrew Godwin wrote:
> So, from what I can work out, this is a proposal for an {% extends %} tag
> which allows you to extend from the parent template of the same name (so it
> looks back in the list of possible templates, and picks the one
Russ,
This will be a welcomed addition to debugging Django apps. I have a question
about startup.py. I notice that startup runs after settings are loaded, but
before models. Does this mean that code within startup.py cannot safely
access the ORM? If the ORM is fully accessible in startup.py, it's
On Thu, Apr 15, 2010 at 9:50 AM, Harro wrote:
> I think the problem isn't the login_required, but it simply does what
> it says it does: Check if the user is logged in.
>
> For me a user with is_active set to false shouldn't be allowed to
> login, they either just created an
If two different threads have a reference to a single model instance,
both can call the instance's delete() method. Only one of the threads
will perform the actual deletion from the database, but both will send
a post_delete signal. This can cause a number of race conditions with
signal