On Fri, 2008-02-15 at 16:37 +1100, Malcolm Tredinnick wrote:
[...]
> The change wasn't made solely because of the speed benefits. Models just
> aren't created that often for it to be the most relevant factor (__new__
> is only called import time normally). It was also made because it makes
> the
> I understand this may be a corner case, but the ability to extend
> Django's initialization is really nice, and this optimization makes the
> code ugly on the applications side (and was there really a need for an
> optimization ? "1-1.5s per 1 models" does not tell much on what has
> been
On Fri, 2008-02-15 at 02:47 +0100, Luper Rouch wrote:
[...]
> CustomModel is not Model, but as it is not initialized by Django it does
> not have a _meta attribute either (and I don't want it initialized by
> Django because it would create a *_custommodel table, plus the extra
> unnecessary
On Thu, 2008-02-14 at 08:49 -0800, aconbere wrote:
[...]
> +1 I'm all for changes that make things consistent with the behavior
> of python.
Well, let's not overrate the importance of this. That particular code
would only have been visible if you did something dumb. It wasn't going
to mislead
On Feb 13, 11:14 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> There's a bunch of code in ModelForms.__new__ that tries to protect
> people from themselves for what looks like a real edge case.
>
> In normal Python code, if you have a class that subclasses from multiple
> parents and you
On Thu, Feb 14, 2008 at 1:14 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
> Any strong objections to not behaving like Python here?
No. Please make the change. I was looking at this the other day and
had one of those "did I really write this?" moments. Thank you for
taking care of #6337
On Thu, Feb 14, 2008 at 1:14 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> Any strong objections to not behaving like Python here?
Sounds like it's well worth removing. +1.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
On Thu, 2008-02-14 at 07:12 -0800, Michael Newman wrote:
>
> > The idea is to replace contrib.comments a bit prior to 1.0. So patches
> > to the existing contrib.comments probably aren't that useful at the
> > moment. Jacob's already done a lot of the work on the rewrite. Stay away
> > from
> I made a patch for Django to add QuerySet.fields(*fields,
> **related_fields) and make possible to load only some from master and
> related models fields. It allows to tune various object list queries
> when we need only limited subset of all fields, improve general
> performance and decrease
> The idea is to replace contrib.comments a bit prior to 1.0. So patches
> to the existing contrib.comments probably aren't that useful at the
> moment. Jacob's already done a lot of the work on the rewrite. Stay away
> from that for the time being.
That's why I ask before I do. Is Jacob also
For me this was like opening pandora's box. As I am following that
ticket, I realized that contrib.comments still uses old forms as well.
If Russ is right (and I think he is), then that will need to be
rewritten too. I will gladly do this considering I got my old form
converting down when I
On Thu, 2008-02-14 at 03:50 -0800, Entropy Hacker wrote:
> I made a patch for Django to add QuerySet.fields(*fields,
> **related_fields) and make possible to load only some from master and
> related models fields. It allows to tune various object list queries
> when we need only limited subset
I made a patch for Django to add QuerySet.fields(*fields,
**related_fields) and make possible to load only some from master and
related models fields. It allows to tune various object list queries
when we need only limited subset of all fields, improve general
performance and decrease database
On Thu, Feb 14, 2008 at 8:14 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> Any strong objections to not behaving like Python here?
The less magic the better.
--
Patryk Zawadzki
PLD Linux Distribution
--~--~-~--~~~---~--~~
You received this message
14 matches
Mail list logo
