Re: #9344 and policy for small bug reports

[Malcolm Tredinnick]

On Sun, 2009-02-08 at 09:22 -0800, rajeesh wrote:
> I just want to register a similar issue. Had opened a ticket, #10057,
> with patch on a trivial matter as http://code.djangoproject.com/ticket/10057.
> Haven't found even any comments regarding its feasibility etc. Can't
> figure out whether people are engaged for some milestone coming but
> this seems to be a bad time. Lot of tickets are there remaining to be
> un-reviewed. Feel like It'll be better If we can at least review the
> problem as soon as possible.

Anybody can review tickets (shouldn't review your own, for obvious
reasons). So if there are patches out there, start going through them.

The current timing is significant. Once we get a couple of things
knocked off and 1.1-alpha out the door, a few of us (and me, in
particular) will have more time to just dive in and start
closing/commiting/bouncing back tickets. It's not too hard to knock off
100 in a few days.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Interaction of annotate() and values()

[Malcolm Tredinnick]

On Sun, 2009-02-08 at 15:56 +0900, Russell Keith-Magee wrote:
[...]
> There is a slight complication, though. The ordering of values() and
> annotate() is significant - values() controls the grouping of
> annotated values if it precedes the annotate().

This is the nub of the problem, isn't it. We possibly messed up here by
overloading what values() does/means. :-(

Problem is, adding a new API to specify the grouping order has the same
drawbacks as having to write values() twice -- you end up needing to
name the fields once for values() and once for the order they group by
and then you think about maybe extracting the latter info from the
former and we're back where we started.

>  However, you can't
> mention the annotated column in a values() clause before it is
> specified, so are left in a situation where you can't actually return
> the annotated value. For example in the query:
> 
> >>> Book.values('title','isbn').annotate(n_authors=Count('authors'))
> 
> n_authors wouldn't be returned in the result set, and there isn't any
> way to add it to the returned values.
> 
> So - some options:
> 
> 1) Leave things as-is. Annotated columns always appear in the result
> set. This is inconsistent with extra(), and means you can't use
> annotated queries in __in clauses.

Unintuitive and inconsistent. As much as I'm willing to declare extra()
the odd man out for most API consistency arguments and as an example of
solid behaviour, I like the current behaviour with
extra(...).values(...).

> 
> 2) Modify things slightly - annotate() calls before a values() call
> aren't automatically added to the results, but annotate() calls after
> values() are included automatically. This would allow annotations to
> always be returned, optionally under those circumstances that allow
> (i.e., annotate() before values()).

This is probably the least intrusive and most supportable option.

> 
> 3) Rely on multiple calls to values() to get annotate columns into the
> result set. i.e., the previous example would need to become something
> like:
> 
> >>> Book.values('title','isbn').annotate(n_authors=Count('authors')).values('title','isbn','n_authors')
> 
> This has the potential to be a bit fragile - we would need to put in
> all sorts of checks for changes in column lists between successive
> calls to values() - but it would allow all combinations of annotation.

No, really... you were just throwing this out to see how it sounded when
it the wall and broke, right? Not a good option.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Custom FilterSpecs #5833 planned for Django 1.1?

[Malcolm Tredinnick]

On Sun, 2009-02-08 at 10:23 -0800, Ben Gerdemann wrote:

> This seems kind of
> ugly, but I'll bet there are many frameworks out there that simply
> ignore unknown parameters. Thoughts?

Ignoring portions of a URL sounds pretty broken. Our goal isn't to be
like other frameworks. It's to behave correctly, in accordance with best
practices for things like URL construction and consumption. I would be a
little unhappy with 'ignoring' being something that happened there.

Regards,
Malcolm



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Custom date formats and admin

[Malcolm Tredinnick]

On Sat, 2009-02-07 at 12:35 +0100, David Larlet wrote:
[...]
> Then on validation, my first idea was to allow  
> form.fields.DEFAULT_DATE/TIME_INPUT_FORMATS to be overridden by  
> settings and I think it makes sense because from my experience, when  
> you decide to create a website (let's say, in French) you do not want  
> to pass your custom input_formats argument to all your fields. I know,  
> I can add a FRDate/TimeField in localflavor but it doesn't solve the  
> admin issue either. Are there drawbacks to this approach?

Yes, ideally, some subset of the input formats would be translated and
the form would carry some information about the language it expects to
process (which could well be different from the user's locale setting,
since the latter can change and the former won't necessarily). Providing
we make the default "en-us", that's all backwards compatible, too.

We might need to carry that information about what formats are
permissible outside of a PO file, though. Perhaps along with the
information I want to put into 1.1 on things like decimal-separator and
first-day-of-the-week. It's just that a Python list is a much more
natural way of describing that information than trying to force it into
msgid/msgstr format (although the latter is slightly more friendly for
no-think-mode for translators, but sometimes translators have to give a
little, too, since we go out of our way a lot for them already).


> I know that the timing isn't that good because you are working on big  
> 1.1 features but I need it now and I'll work on it so feedback is  
> appreciated before I submit complete patches.

The timing isn't too bad. Getting better i18n support for dates is
something I'm going to work more heavily on after the alpha release,
which could well mean reviewing a whole bunch of patches and applying
things.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: App Engine port

[Malcolm Tredinnick]

On Fri, 2009-02-06 at 03:32 -0800, Waldemar Kornewald wrote:
> Hi Russell,
> 
> On 6 Feb., 11:34, Russell Keith-Magee  wrote:
> > I would suggest to you that the broader project of "modifying the
> > django.db.models interface to be fully independent of SQL" is much
> > more likely to get core developer support. We (the Django core) will
> > be very receptive to any suggestions on how django.db.models needs to
> > be modified in order to support non-SQL backends -- especially if you
> > can demonstrate that your suggestions aren't just theoretical, but are
> > clearly required by an actual backend implementation.
> 
> Agreed, making models SQL-independent is the most important (and most
> complicated) part. Do the people secretly working on App Engine
> integration try to implement that part?

I have a reasonably fleshed out plan to make things easier here in the
Django 1.2 timeframe. The rough idea is that everything under
django/db/models/sql/ could be replaced with a module of the developer's
choosing (probably set via a setting). That package is the only place
that really cares much about SQL.

So somebody wanting a GAE backend or an Hadoop backend or something else
would write something that behaved the same way as the Query class (and
subclasses) and could be called by the QuerySet class appropriately.

There are a few more details involved there than just that one setting,
since it requires documenting the expectations (vs the currently
convenient assumptions) that Queryset will make on the Query class --
probably that's pretty much what's there now, although I have a list
somewhere of a couple/three things I wanted to look at. There's also
simple enough stuff like removing the last vestiges of raw SQL from a
couple of places (most notable related fields, but that should probably
go after, or in tandem with, a rewrite of related fields to clean them
up in general).

There's also some thinking I have to do about where to draw the line for
things like custom lookup types on fields -- how much do we encourage
(with the noisy end of a cattle prod) people to be good
extension-oriented citizens down the track and where can we help.

We've tried pretty hard to keep the SQL-agnostic portions of the API
separates from the database bits. I've made Russell's life a bit harder
lately by asking for -- fairly insistently -- such changes in the
aggregates patch to help with this goal going forwards, for example. The
public API for querysets is fairly SQL agnostic, with the exception of
Black Sheep extra(), and in that latter case, sometimes there's just
nothing you can do about that. We take a fair bit of grief both here and
in django-users for having this position, actually. Lots of requests for
compromises to allow some half-breed combinations of raw SQL and
querysets, which has hidden traps at both the design level and the
extension level we're talking about here. So the changes you're talking
about are certainly possible.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: App Engine port

[Malcolm Tredinnick]

On Fri, 2009-02-06 at 09:51 -0500, David Stenglein wrote:
> I have to ask a question here. Why is there such reticence regarding
> App Engine? It would
> seem to me that App Engine has been a feather in the cap for Django. A
> lot of people don't know Django and at a previous job, I was able to
> say that "Google chose django" for App Engine to help validate my use
> of it.

To echo everybody else; There simply isn't any reticence.

> 
> If so, why the seeming lack of excitement around App Engine? Are
> google engineers not involved in the community?

Possibly. If they are, they aren't posting from their @google.com
addresses, as far as I can see on this list.

I would point out that the original GAE integration with Django could
have been implemented quite differently and a lot of this could have
Just Worked out of the box. However, there were reasonably (not
perfectly) valid corporate and legal reasons why Google chose not to
and/or couldn't do that. So the thing works both ways. Google made some
choices and this thread is now about working around those choices to
integrate more nicely.

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Option to disable messages in auth context processor

[Malcolm Tredinnick]

On Sun, 2009-02-08 at 23:52 -0600, Gary Wilson Jr. wrote:
> On Thu, Feb 5, 2009 at 9:07 AM, Jacob Kaplan-Moss
>  wrote:
> > On Thu, Feb 5, 2009 at 9:01 AM, Vinicius Mendes  wrote:
> >> So I decided to write a new messages app and it works very well, the only
> >> problem is the django.core.context_processors.auth.
> >
> > Yeah, this processor has a bunch of bugs in it. I think Malcolm and I
> > figured out that there's something like five different bugs -- not bad
> > for three lines of code!
> 
> Are these documented anywhere, by chance?
> 
> I know the get_and_delete_messages call is problematic because it
> causes evaluation of the LazyUser object created by the
> AuthenticationMiddleware.  This causes both an access to the session
> (causing #6552 - Vary: Cookie [1]) and an extra query on every request
> to grab the user.

That's two of them.

> 
> What are the other issues?

Querying the auth table on every request is an unnecessary query. I
don't think that's in a ticket anywhere; it's not a functionality bug as
much as an obvious opportunity for optimisation (albeit not completely
trivial).

My memory was there were only three "bugs" in those three lines of code
constructing the returned object, not five.

Regards,
Malcolm



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Testing framework inflexibilities

[Russell Keith-Magee]

On Tue, Feb 10, 2009 at 10:34 AM, Ludvig Ericson
 wrote:
>
> Feb 8, Russell Keith-Magee:
>> First off - it isn't impossible to do what you are describing with the
>> existing setup. There is no reason you couldn't override _pre_setup()
>> in your subclass and either re-instantiate self.client, or modify the
>> self.client instance that has already been created. This isn't
>> necessarily clean, but it would work.
>
> Though I solved my own problem through some means, no - your
> suggestion would not work. The reason is that the TestCase.__call__
> code does: _pre_setup, set client, super...(), _post_setup.

Erm... no it doesn't. Lines 236-245 of testcases.py:

self.client = Client()
try:
self._pre_setup()
except (KeyboardInterrupt, SystemExit):
raise
except Exception:
import sys
result.addError(self, sys.exc_info())
return
super(TransactionTestCase, self).__call__(result)

That's set client, _pre_setup, super(), not _pre_setup, set client, super().

>> This area could certainly be cleaned up, though. Moving the
>> instantiation of Client into _pre_setup() would be one approach.
>> Another would be to parameterize the class that is instantiated when
>> the client is created - i.e., rather than always instantiating
>> django.test.client.Client, we provide a customization hook that lets
>> subclasses provide their own Client class.
>
> A rather common idiom I've seen is:
>
> class TestCase(...):
> client_class = DjangoTestClientThing
>
> def __call__(self, ...):
> # ...
> if self.client_class:
> self.client = self.client_class(...)
> # ...
>
> Essentially achieving the same as you, only because of Python's name
> resolution machinery, you could also do `my_inst.client_class = Blah`
> to specialize per instance.

That's the technique I was referring to. It can be implemented in at
least three ways -
 1) Providing a class level variable that defines the Client class to
be instantiated,
 2) Providing a method that returns the Client class to be instantiated, or
 3) Providing a method that instantiates the client class.

Option (3) is essentially a replacement for setup(), so it's probably
overkill. Personally, I'd be leaning towards (1) - it's easy to
describe, almost impossible to get wrong, and matches the other
configuration options for the TestCase class.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Testing framework inflexibilities

[Ludvig Ericson]

Feb 8, Russell Keith-Magee:
> First off - it isn't impossible to do what you are describing with the
> existing setup. There is no reason you couldn't override _pre_setup()
> in your subclass and either re-instantiate self.client, or modify the
> self.client instance that has already been created. This isn't
> necessarily clean, but it would work.

Though I solved my own problem through some means, no - your  
suggestion would not work. The reason is that the TestCase.__call__  
code does: _pre_setup, set client, super...(), _post_setup.

The only way to hook into that code would be to mash up the MRO for  
TestCase and inject oneself into the super call. And then re-instatiate.

> This area could certainly be cleaned up, though. Moving the
> instantiation of Client into _pre_setup() would be one approach.
> Another would be to parameterize the class that is instantiated when
> the client is created - i.e., rather than always instantiating
> django.test.client.Client, we provide a customization hook that lets
> subclasses provide their own Client class.

A rather common idiom I've seen is:

 class TestCase(...):
 client_class = DjangoTestClientThing

 def __call__(self, ...):
 # ...
 if self.client_class:
 self.client = self.client_class(...)
 # ...

Essentially achieving the same as you, only because of Python's name  
resolution machinery, you could also do `my_inst.client_class = Blah`  
to specialize per instance.

> Patches welcome. :-)


Once I know what to write!

- Ludvig

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---