Re: [GSoC] Revamping validation framework and merging django-secure once again

Hi Christopher, Overall, this looks like a great project and I look forward to the more flexible validation hooks. As the author of django-secure, I do have one concern with the implementation plan: Django's existing validation checks are intended to be run in development, as a debugging aid,

[GSoC] Revamping validation framework and merging django-secure once again

Hello! I'm really happy that I've been accepted as a Google Summer of Code student. I will work at revamping validation framework and merging django-secure this summer. I created this thread to start discussion (especially about public API) and get some feedback as well as to share progress. Any

Re: Not calling things twice in templates

Hi, On Monday 03 June 2013, Andre Terra wrote: > Well, Russ, you asked for suggestions, so here's a couple half-hearted > attempts. > ... and here's a couple of other ones, mostly inspired by those: > {% with my_bonnet.bees as bees if my_bonnet.bees %} > {% if my_bonnet.bees with

Re: Make sure QuerySet.get() does not fetch more rows than it absolutely needs

On Monday 03 June 2013, Patryk Zawadzki wrote: > Here's the ticket: > > https://code.djangoproject.com/ticket/6785 > > tl;dr: Calling .get() on a badly filtered queryset can result in lots > of database rows being fetched and wrapped in Python objects for no > gain. > tl;dr: There's a general,

Re: Username Independence in Auth Forms

> The current code assumes that if you write a custom model, you'll also write the corresponding custom forms. Right. This is what I am proposing be fixed. On Mon, Jun 3, 2013 at 12:31 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 3 juin 2013, at 20:01,

Re: Username Independence in Auth Forms

On 3 juin 2013, at 20:01, gavinw...@gmail.com wrote: > Some of the built-in auth forms only work on user models whose > `USERNAME_FIELD` is `username`. Hi Gavin, The current code assumes that if you write a custom model, you'll also write the corresponding custom forms. You may want to have

Username Independence in Auth Forms

Some of the built-in auth forms only work on user models whose `USERNAME_FIELD` is `username`. It is possible to remove this constraint and allow them work on any user model. [django-authtools][1] demonstrates this possibility. The two forms in question are `UserCreationForm` and

Re: RFC: "universal" view decorators

Attempting to make decorators anticipate every usage is the wrong approach. In Django, the sole interface to a view is as a callable that accepts an `HttpRequest` and turns it into an `HttpResponse` or exception. Django the framework doesn't actually need to support class-based views--because

Re: Why apps have to have unique names? [related with subapps and name collision]

Related thread: https://groups.google.com/d/topic/django-developers/9piN0wRFbLs/discussion -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Make sure QuerySet.get() does not fetch more rows than it absolutely needs

Here's the ticket: https://code.djangoproject.com/ticket/6785 tl;dr: Calling .get() on a badly filtered queryset can result in lots of database rows being fetched and wrapped in Python objects for no gain. Currently .get() logic is as follows: clone the queryset, prepopulate its full cache,

Re: Not calling things twice in templates

By the way, this could also be implemented using just files. The way {% include %} works for macros. If that's preferred. That becomes: {% decorate "my_special_for.html" data %} {{ i.value }} {% enddecorate %} Le lundi 3 juin 2013 13:38:29 UTC+2, Jonathan Slenders a écrit : > > Hi all.

Re: Not calling things twice in templates

Hi all. In the past, I once proposed a decorate template tag, but it was disapproved back then. This would be another solution, to make the template language a lot more powerful. 1. First you define a decorator, for the behaviour you'd like to have. The "data" parameter indicates the receiving

Re: Why apps have to have unique names? [related with subapps and name collision]

On Mon, Jun 03, 2013 at 01:04:34PM +0300, Yishai Beeri wrote: > Is this not almost trivial to work around by creating a new module > 'newapp', importing the original app code from it, and then using > 'path.to.newapp' as a new "copy" of the app in INSTALLED_APPS? Not really. At least not for

Re: Making __repr__ safe by default

2013/5/19 Karen Tracey : > I agree with Anssi, repr should stay as-is. I do a lot of shell/pdb work and In interactive mode it's just as easy to call __unicode__ as it is to call __repr__. On the other hand __repr__ is used by automated tools such as crash reporters (raven).

Re: Not calling things twice in templates

2013/6/3 Andre Terra : > Well, Russ, you asked for suggestions, so here's a couple half-hearted > attempts. > > Perhaps we could allow for if clauses in the with block or vice-versa? It > could be argued that it would reduce readability and/or induce confusion > with

Re: Why apps have to have unique names? [related with subapps and name collision]

Is this not almost trivial to work around by creating a new module 'newapp', importing the original app code from it, and then using 'path.to.newapp' as a new "copy" of the app in INSTALLED_APPS? Yishai On Mon, 03 Jun 2013 12:24:38 +0300, Aymeric Augustin

Re: Why apps have to have unique names? [related with subapps and name collision]

2013/6/3 Jorge C. Leitão Motivated by that criticism, I want to ask: why apps have to have unique > names? > Hi Jorge, Django assumes that a model can be identified by (app_name, model_name). Long ago — 8 years ago — it didn't seem to be a problem. I'm not sure your

Re: Composite fields once again

On 2 kesä, 23:20, Luke Sneeringer wrote: > On Jun 2, 2013, at 8:22 AM, Michal Petrucha wrote: > > > GenericForeignKey and nontrivial field types > > > > > As I've indicated in my proposal, just casting

Why apps have to have unique names? [related with subapps and name collision]

Hi. The motivation to this question is that if I want to implement "copies" of an app within an website (for instance, a stackoverflow-like where each app is a Q for its own, but with modifications on templates, urls, etc.), as far as I'm understanding: (1) each "copy" has to change its name,

Re: Not calling things twice in templates

On Mon, Jun 3, 2013, Russell Keith-Magee wrote: >> But this is another common pattern: >> >> {% if my_bonnet.bees %} >> >> {% for bee in my_bonnet.bees %} >> {{ bee }} >> ... >> >> The problem here is that my_bonnet.bees gets asked

Re: Not calling things twice in templates

On Mon, Jun 3, 2013 at 1:20 PM, Shai Berger wrote: > On Monday 03 June 2013, Russell Keith-Magee wrote: > > Alternatively, add new sub tags to {% for %}: > > > > {% for bee in my_bonnet.bees %} > > {% pre %} > > > > {% body %} > > {{ bee }} > > {% post %} > > > > {%