Re: reset and sqlreset - PendingDeprecationWarning

On Tue, Oct 5, 2010 at 1:22 PM, ptone wrote: > > > On Oct 4, 7:37 pm, Russell Keith-Magee > wrote: >> On Tue, Oct 5, 2010 at 10:02 AM, Laurent Luce >> wrote: >> > Thanks for those details. In case someone is using those

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 3:16 AM, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > >> Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor >

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 5:43 AM, George Sakkis wrote: > On Oct 4, 10:55 pm, "David P. Novakovic" > wrote: >> On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis >> wrote: >> >> > Since dispatch is going to be defined on the

Re: reset and sqlreset - PendingDeprecationWarning

On Tue, Oct 5, 2010 at 10:02 AM, Laurent Luce wrote: > Thanks for those details. In case someone is using those commands and > is kind of happy with them, what would be the alternative? sql_reset = > sql_delete + sql_add but those commands are not exposed so I am >

Re: ANN: Improving our decision-making and committer process

On Tue, Oct 5, 2010 at 9:58 AM, Tai Lee wrote: > Hi Russ, > > On Oct 5, 11:48 am, Russell Keith-Magee > wrote: > >> > Perhaps we need another triage stage for these tickets, "Needs final >> > review" or something? >> >> That's essentially what

Re: reset and sqlreset - PendingDeprecationWarning

Thanks for those details. In case someone is using those commands and is kind of happy with them, what would be the alternative? sql_reset = sql_delete + sql_add but those commands are not exposed so I am wondering. Laurent On Oct 4, 4:54 pm, Russell Keith-Magee wrote:

Re: ANN: Improving our decision-making and committer process

Hi Russ, On Oct 5, 11:48 am, Russell Keith-Magee wrote: > There have been a couple of suggestions recently that the contributing > guide should be distilled into a specific HOWTO for new users. I > suppose the idea here would be for the contribution guide to be the >

Re: ANN: Improving our decision-making and committer process

On Tue, Oct 5, 2010 at 8:16 AM, Tai Lee wrote: > Hi Jacob, > > Thanks for your feedback. > >> For (1) check out http://code.djangoproject.com/wiki/Reports(it's >> linked in the nav). If there's anything missing there, please feel >> free to add it -- it's a wiki page.

Re: variable view name in url tag

On Tue, Oct 5, 2010 at 7:27 AM, SmileyChris wrote: > Just throwing the idea out there, it would be possible to keep the tag > completely backwards compatible by using a slightly different syntax > for variables. > > Standard non-variable access stays the same: {% url home

Re: ANN: Improving our decision-making and committer process

Hi Jacob, Thanks for your feedback. > For (1) check out http://code.djangoproject.com/wiki/Reports(it's > linked in the nav). If there's anything missing there, please feel > free to add it -- it's a wiki page. Let me know if you need help > figuring out the linked query syntax. I wasn't able

#13914 Add natural keys to contrib.auth.User and Group models

I am currently using the patch provided in the ticket http://code.djangoproject.com/ticket/13914 in my Django project. It's a small change, but I find it to be very helpful. Since the ticket seems to be be inactive I decided to come here and ask for someone to review it. I am not very familiar

Re: reset and sqlreset - PendingDeprecationWarning

On Tue, Oct 5, 2010 at 2:55 AM, Laurent Luce wrote: > Hello, > > I am looking at ticket #14268 on reset and sqlreset management > commands should raise PendingDeprecationWarning for 1.3. > > I added some code to django/core/management/commands/reset.py and >

Re: variable view name in url tag

Just throwing the idea out there, it would be possible to keep the tag completely backwards compatible by using a slightly different syntax for variables. Standard non-variable access stays the same: {% url home %}, {% url edit-profile profile.pk %} Variable access is done via a "var=" first

Re: variable view name in url tag

On Tuesday, 5 October 2010 at 12:17 AM, Sean Brant wrote: On Oct 3, 8:08 pm, Russell Keith-Magee wrote: On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant wrote: > Thanks for the feedback Russ. I know it couldn't be that straight

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 10:55 pm, "David P. Novakovic" wrote: > On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote: > > > Since dispatch is going to be defined on the base View class, can't we > > omit it from the urlconf and have the URLresolver do: > > >  

Site app should be able to make absolute URLs #10944

Hello, I added a patch to this ticket http://code.djangoproject.com/ ticket/10944">#10944 - add method get_url to Site model to return an absolute url based on a relative path passed as an argument. - add site_url template tag doing the same I am not sure about the method and template tag

Re: #6735 -- Class based generic views: call for comment

I agree with George, and would like to not have to write the dispatch out every time, but my only concern is how confusing an implicit dispatch would be for developers first using the new class-based Views system. As long as it was made abundantly clear via the docs what exactly is happening when

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote: > > Since dispatch is going to be defined on the base View class, can't we > omit it from the urlconf and have the URLresolver do: > >  if isinstance(view, type) and issubclass(view, View): >      view = view.dispatch

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 9:16 pm, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > > Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor > arguments to

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 7:22 pm, Jacob Kaplan-Moss wrote: > On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: > > Given that the primary complain against the __new__ solution is that > > it's unintuitive to Python programmers that instantiating their class > >

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Last idea, I swear, I didn't swear, so here is another slight variation :-) You actually *call* the classmethod in your URLconf, passing any constructor arguments to it: url(r'^detail/author/(?P\d+)/$',

reset and sqlreset - PendingDeprecationWarning

Hello, I am looking at ticket #14268 on reset and sqlreset management commands should raise PendingDeprecationWarning for 1.3. I added some code to django/core/management/commands/reset.py and django/core/management/sql.py to raise the appropriate warning. What message should I displayed ? I

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 20:03, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: >> Given that the primary complain against the __new__ solution is that >> it's unintuitive to Python programmers that instantiating their class >> results in some other

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod. Simply used as:

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 19:37 +0200, Łukasz Rekucki wrote: > The only problem is decorators: You can't just simply apply > login_required() to the class or the dispatch() method. Otherwise, I > like this approach. It works fine:

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 19:22, Jacob Kaplan-Moss wrote: > On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: >> Given that the primary complain against the __new__ solution is that >> it's unintuitive to Python programmers that instantiating their class >>

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod. Simply used

Re: Contributing more

Thank you all for the great insights. On Oct 3, 8:07 pm, Russell Keith-Magee wrote: > On Mon, Oct 4, 2010 at 10:11 AM, Laurent Luce wrote: > > Hello, > > > I added the localflavor for Belgium as my first contribution. I would > > like to

Re: #6735 -- Class based generic views: call for comment

On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit >

Re: #6735 -- Class based generic views: call for comment

On Mon, Oct 4, 2010 at 1:04 PM, Andrew Godwin wrote: > On 04/10/10 17:28, legutierr wrote: >> >>   * First, treat data processing and retrieval as separable from >> rendering.  Create a bright line of separation between the two >> conceptual elements of the view (data and

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 10:32 pm, Russell Keith-Magee wrote: > I completely agree that we don't want to rush this. The upside is that > if we *can* reach consensus, it isn't going to require a whole lot of > code changes; We're arguing about how to architect the base class, but > once

Re: #6735 -- Class based generic views: call for comment

> > On Mon, Oct 4, 2010 at 8:08 AM, Andrew Godwin wrote: > > I'd just like to add more noise to the signal and reiterate this - storing > state on self (or request) leads to much cleaner, less fragile, more > subclassable views (in my own experience, having written both a

Re: variable view name in url tag

On Oct 3, 8:08 pm, Russell Keith-Magee wrote: > On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant wrote: > > > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote: > > >> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant wrote: > >>> I

Re: rethinking raw_id_fields

Righton. I haven't used it too intensely for filtering and sorting but I do have some other thoughts about that. 1) Would it be better to come up with a non-changelist changelist for raw_id_fields. I find myself avoiding raw_id_fields because I don't necessarily want to register the object in

Re: #6735 -- Class based generic views: call for comment

On 03/10/10 03:20, Russell Keith-Magee wrote: * Ignore the legitimate occasions where using state is a useful architectural approach. I'd just like to add more noise to the signal and reiterate this - storing state on self (or request) leads to much cleaner, less fragile, more

Re: rethinking raw_id_fields

On 4 Ott, 04:09, Chuck Harmston wrote: > An Ajax admin solution (of the autocomplete sort, which I presume is what > you're proposing) does not have the same use case for raw_id_fields. It's > based on the assumption that the user knows the value of the unicode >

Re: #12991 unittest2 support - Second call for comment

On Oct 2, 11:27 pm, Russell Keith-Magee wrote: > Hi all, > > I've just uploaded a second alpha of the patch introducing unittest2 > into Django's core [1]. As with last time, help is requested running > the test suite on different Python versions and different databases.

Re: rethinking raw_id_fields

We're playing semantic leapfrog here, but I don't see the proposed Ajax solution as "searching", I see it as "autocompleting"; people won't use it to discover content, they will use it as a shortcut for accessing content that they are familiar with. As I said, much of the utility of the

Re: Sites Framework: RequestSite and get_current

There is now a ticket and a patch for this, which includes the utility method and a rollup of fixes for the aforementioned tickets as appropriate. Tests and docs included. Details are in the ticket description: http://code.djangoproject.com/ticket/14386 I'd love to get some feedback on it when

Re: Proposal: Meta.required_together

Sorry I didn't reread this thread, or remembered it after my previous post. I just replied to clearify my previous post. Tino On Mon, Oct 4, 2010 at 02:57, LookMa NoSQL wrote: > Tino, are you joking? Did you even bother to read the OP's proposal. I > think there is a

Re: Sites Framework: RequestSite and get_current

Hi Gabriel, looking good! On Mon, Oct 4, 2010 at 2:59 PM, Gabriel Hurley wrote: > There is now a ticket and a patch for this, which includes the utility > method and a rollup of fixes for the aforementioned tickets as > appropriate. Tests and docs included. Details are in the