Re: reset and sqlreset - PendingDeprecationWarning

2010-10-04 Thread Russell Keith-Magee
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 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.
>>
>> It depends a little on what they were doing in the first place. flush
>> is the nuclear option, because it deletes *everything*; another would
>> be learning how to use ALTER TABLE or DROP TABLE statements manually.
>
> I'm sure the reasoning is sound in the decision to remove these, but
> given that flush is db wide and not app targeted - this removes a
> certain functionality without any documentation as to why it is being
> removed.  The ticket only says "These commands break a lot" which
> leaves a little room for clarification - either on the ticket or in
> the docs.  I'm sure a number of people use reset when doing early
> revisions on the models of an app, who don't need/want to flush the
> whole db, and who don't need/want to drop into the db-shell to drop
> tables.  Even with South, I use reset early on sometimes when I'm
> roughly sketching out a model.  I know this is only a warning, but
> seems might as well bring it up now while there is already a thread on
> it.

I've just updated the ticket details to provide a slightly better
explanation of the reasoning for the deprecation.

The problem is that the SQL generated by sqlreset doesn't work in all
circumstances. This isn't a problem on databases without referential
integrity (SQLite, and MySQL with MyISAM tables), but once you have
referential integrity, you can't just drop tables without considering
the order in which they are dropped, and possibly doing lots of manual
relaxation of foreign key constraints.

As the closing comment on #2493 says, Django just can't substitute for
a good DBA when it comes to this problem.

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-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Russell Keith-Magee
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
> arguments to it:
>
> url(r'^detail/author/(?P\d+)/$',
>        views.AuthorDetail.as_view(some_param=123),
>        name="author_detail"),
>
> It returns a newly created view function, which in turn calls your
> class.
>
> http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/classmethod2.py

This looks to me like it could be a winner. The fact that
AuthorDetail(foo=bar).as_view(pork=spam) ignores the 'foo' argument is
a minor wart, but a lot less concerning to me that the potential
threading problems in copy+call, or the 'no state on self' options.

Thanks for working up the examples, Luke!

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Russell Keith-Magee
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 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
>>
>> Russ mentioned this one can't be decorated.
>
> What does "this" refer to here ? It's just a shortcut for the common
> case, you can always decorate the SomeClassView.dispatch:
>
> url("^articles1/$", ArticlesView.dispatch),                 #
> undecorated
> url("^articles2/$", login_required(ArticlesView.dispatch)), #
> decorated
>
> url("^articles3/$", ArticlesView),                   # shortcut of the
> first
> # url("^articles4/$", login_required(ArticlesView)), # this doesn't
> work
>
> There is an asymmetry here but that's not to say it can't be
> decorated, you just have to decorate the dispatch method instead of
> the class view.

Yes, but that's the sort of asymmetry I'd like to avoid if possible.
It's easy to document that you can wrap a decorator around anything
you can put in a URL pattern. When you start making exceptions, then
you have to explain the exceptions, and then explain to the people who
don't read and/or understand the explanation... and so on.

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-develop...@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: reset and sqlreset - PendingDeprecationWarning

2010-10-04 Thread Russell Keith-Magee
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
> wondering.

It depends a little on what they were doing in the first place. flush
is the nuclear option, because it deletes *everything*; another would
be learning how to use ALTER TABLE or DROP TABLE statements manually.

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-develop...@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: ANN: Improving our decision-making and committer process

2010-10-04 Thread Russell Keith-Magee
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 RFC is. This is an area where our documented
>> procedures have lagged behind in-practice procedures, but we've
>> essentially accepted that once a patch has been written by one person,
>> and reviewed by another and found to be ok, then it's RFC, which means
>> a core committer needs to take a look.
>
> I'm happy for RFC to indicate that a ticket is ready for final review
> by a core committer, after being reviewed by at least someone other
> than the patch author. But, I think there's still a problem of
> accepted tickets that have a patch with docs and tests and no feedback
> indicating that it needs improvement, being lost in the shuffle, as
> well as how and why we ever end up with tickets in this state and how
> can the patch author get someone to review their work.

You can get a list of tickets that meet that criterion very easily -
it's tickets in "accepted" with a "patch needs improvement" flag.

This doesn't solve the problem of people who review a ticket, but
don't flick the "patch needs improvement" flag or provide feedback on
what exactly is wrong... but no technological solution will fix those
problem. The best we can hope for here is for a second reviewer to
come along and clean up the ticket state.

> It could happen that a ticket is accepted on merit, then it gets a
> patch with docs and tests, and then sits there getting no attention
> because nobody knows it needs a review. The patch author could just
> move it to RFC themselves as it had previously been accepted and he or
> she subsequently added the required docs and tests, in order to get
> somebody to look at it. But I think this is generally frowned upon and
> might take up too much core committer attention before the ticket is
> really ready.
>
> It could also happen that a ticket is unreviewed and already has a
> patch with docs and tests, if it is reviewed by a core committer (or
> not) and "accepted" without feedback about any necessary improvements,
> shouldn't it have simply gone straight to RFC instead? What should the
> original patch author do when his or her patch with docs and tests is
> reviewed by someone else and moved to "accepted" like this? There's no
> feedback that they need to incorporate into the patch, and they can't
> move their own work to RFC, even though someone else has reviewed and
> "accepted" the patch?
>
> I'd like to see the ticket system work smoothly in and of itself, and
> for tickets to be reviewed without the patch authors having to ask
> around on IRC or django-developers for someone to take a look. I don't
> want to make the ticket system too complicated, but I think it is
> already a bit muddled by determining whether or not a ticket needs
> review by checking 5 or 6 different properties, instead of a single
> clear indicator set by the patch author that he or she would like
> somebody (not necessarily a core committer) to review the work. This
> could also help in eliminating another problem of not knowing if a
> ticket is still being worked on or if the patch author considers it
> finished.

The problems you describe here fall into a couple of categories:

 * People doing triage, but not setting flags or giving feedback
correctly. This is a social problem; no technology is going to fix it
-- especially not adding *more* flags to our Trac configuration.
Improved documentation of what we expect *might* improve things here;
suggestions (and patches!) are welcome.

 * Improving visibility of work that needs to be done. This is
somewhere that Trac gardening is needed -- the relevant queries aren't
hard to write; they just need to be made more prominent.

 * Determining which ticket out of hundreds require attention. Two
ways to slice this that aren't currently available to us are ordering
by last modification date, and ordering by "popularity" (as determined
by users voting on tickets). Right now, the biggest impediment is that
our Trac install is *really* old, so all the nice new plugins
implementing these features won't run. We're in the process of
upgrading Trac; once that is done, we'll be able to add some of these
new features.

The only edge case I can see that you've identified that we don't
cover is people who upload incomplete patches which they *don't* want
reviewed yet. I don't see this as a major problem -- in my experience,
people upload patches because they think they're ready. Patches may
not always be correct, but I haven't seen a lot of people using Trac
as a temporary storage area for incomplete work. If someone uploads a
patch, they're generally looking for *some* feedback, even if it's
just "am I on the right track?"

>> As a general principle, DDN isn't usually a situation where 

Re: reset and sqlreset - PendingDeprecationWarning

2010-10-04 Thread Laurent Luce
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:
> 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
> > django/core/management/sql.py to raise the appropriate warning.
>
> > What message should I displayed ? I have the following right now:
> > "This command is pending deprecation." I know it is not really
> > insightful. The real reason is that those commands don't work well but
> > I don't think we want to have that as the message.
>
> Something short and pithy is all you need. There are a couple of
> existing PendingDeprecationWarnings in Django's code already; use
> those as a guide for appropriate style.
>
> Don't get too concerned about getting the text completely perfect,
> though; a core committer will probably give the text a polish before
> they commit.
>
> > I guess I also need to update docs/releases/1.3.txt with an
> > explanation on why deprecation is pending.
>
> Correct. Again, don't get too concerned about the exact text --
> documentation is almost *always* polished before committing.
>
> > Finally, do I need to update the following files with the warning
> > information.
> > docs/ref/django-admin.txt
> > docs/man/django-admin.1
>
> Yes. In ref/django-admin.txt, you can use a Sphinx annotation to
> declare the deprecated feature:
>
> .. deprecated:: 1.3
>
> There are a couple of other uses of this in the docs, so search around
> for examples of usage. You might also want to do a quick audit of
> django-admin.1 to check that we actually have all the builtin admin
> commands... I have a sneaking suspicion there might be a couple
> missing.
>
> 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-develop...@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: ANN: Improving our decision-making and committer process

2010-10-04 Thread Tai Lee
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
> letter of the law, and the HOWTO to be the spirit of the law -- a
> lightweight guide pointing people at some specific activities they
> could engage in as a new contributor.

I see. Sounds reasonable. I can see that it might be difficult to
extract the relevant information from the full contributing guide for
newbies, as well as for long time users wanting a quick reference.

> > Perhaps we need another triage stage for these tickets, "Needs final
> > review" or something?
>
> That's essentially what RFC is. This is an area where our documented
> procedures have lagged behind in-practice procedures, but we've
> essentially accepted that once a patch has been written by one person,
> and reviewed by another and found to be ok, then it's RFC, which means
> a core committer needs to take a look.

I'm happy for RFC to indicate that a ticket is ready for final review
by a core committer, after being reviewed by at least someone other
than the patch author. But, I think there's still a problem of
accepted tickets that have a patch with docs and tests and no feedback
indicating that it needs improvement, being lost in the shuffle, as
well as how and why we ever end up with tickets in this state and how
can the patch author get someone to review their work.

It could happen that a ticket is accepted on merit, then it gets a
patch with docs and tests, and then sits there getting no attention
because nobody knows it needs a review. The patch author could just
move it to RFC themselves as it had previously been accepted and he or
she subsequently added the required docs and tests, in order to get
somebody to look at it. But I think this is generally frowned upon and
might take up too much core committer attention before the ticket is
really ready.

It could also happen that a ticket is unreviewed and already has a
patch with docs and tests, if it is reviewed by a core committer (or
not) and "accepted" without feedback about any necessary improvements,
shouldn't it have simply gone straight to RFC instead? What should the
original patch author do when his or her patch with docs and tests is
reviewed by someone else and moved to "accepted" like this? There's no
feedback that they need to incorporate into the patch, and they can't
move their own work to RFC, even though someone else has reviewed and
"accepted" the patch?

I'd like to see the ticket system work smoothly in and of itself, and
for tickets to be reviewed without the patch authors having to ask
around on IRC or django-developers for someone to take a look. I don't
want to make the ticket system too complicated, but I think it is
already a bit muddled by determining whether or not a ticket needs
review by checking 5 or 6 different properties, instead of a single
clear indicator set by the patch author that he or she would like
somebody (not necessarily a core committer) to review the work. This
could also help in eliminating another problem of not knowing if a
ticket is still being worked on or if the patch author considers it
finished.

> As a general principle, DDN isn't usually a situation where more
> information is needed; it's usually just time that is lacking.
>
> Sprints definitely help push this sort of thing along. However, that's
> more because we have two core developers in a room at the same time,
> not because of the presence of the rest of the community (although the
> community got lots of other great work done). Malcolm and I spend a
> day at the recent sprints just doing DDN tickets, and we managed to
> clear out quite a few DDNs. We made vague plans to hook up on
> IRC/Skype as a semi-regular activity to try and clear out the backlog,
> but we haven't made that happen yet.

Are at least two core committers required for all DDN tickets? Can a a
single core committer make decisions on minor or trivial tickets, and
the reporter be given the option to request a vote or further
consideration if they feel the decision is wrong (possibly based on
lack of information)? Perhaps some of the people who are well known
and long standing in the community (but who don't have commit access)
could make some of these decisions?

Cheers.
Tai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: ANN: Improving our decision-making and committer process

2010-10-04 Thread Russell Keith-Magee
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. Let me know if you need help
>> figuring out the linked query syntax.
>
> I wasn't able to edit this page. Other wiki pages have an "Edit this
> page" and "Attach file" buttons at the bottom, but not the Reports
> page.

It looks like that page has been locked down to prevent bad edits.
I'll put some wiki gardening on my todo list.

>> Work on (2) began at some point over 
>> athttp://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough
>> still, but once it gets better I'd love to link sections from the
>> ticket page and/or move it into the docs directly.
>
> This is good, but it looks like mostly copy and paste from the
> "Contributing to Django" docs (duplication of data, also the Wiki is
> not authoritative, especially when not authored by a core committer)
> for the descriptions of each triage stage and patch flag, with the
> addition of next steps. I'm also not sure if this Wiki page is linked
> to from anywhere (e.g. actual ticket pages)?
>
> Perhaps we'd be better off simply adding the next steps information to
> the "Contributing to Django" docs directly, and to also update the
> diagram there to include the various patch flags (has patch, needs
> docs, needs tests, patch needs improvement) between the Accepted and
> Ready for checkin triage stages?

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
letter of the law, and the HOWTO to be the spirit of the law -- a
lightweight guide pointing people at some specific activities they
could engage in as a new contributor.

> Perhaps we need another triage stage for these tickets, "Needs final
> review" or something?

That's essentially what RFC is. This is an area where our documented
procedures have lagged behind in-practice procedures, but we've
essentially accepted that once a patch has been written by one person,
and reviewed by another and found to be ok, then it's RFC, which means
a core committer needs to take a look.

>> Ideally, I'd like each ticket page to have a "what's next?" box on it
>> indicating where the ticket is and how to move it along. Technically
>> this isn't hard -- we've got plenty of folks in our community who
>> could write a Trac plugin -- but getting the language right is
>> important. If we get that worked out to some extent I'll figure out
>> what the next steps are technically.
>
> Perhaps another boolean flag that simply says if the next step lies
> with the patch author / community, or with the core committers?
> Similar to regular support tickets which might say "waiting on
> customer" or "waiting on support staff". This could help avoid
> situations where the patch author thinks they've done everything they
> need to do, satisfied all the requirements (docs, tests, code style),
> and yet their ticket is never pushed up to Ready for checkin, which
> only makes them less likely to contribute again in future and more
> likely to simply fix or work around their problem locally instead and
> save writing docs and tests for Django that go unused.

I don't know if another boolean flag is what is needed -- that strikes
me as more Trac gardening that can be mistriaged. Plus, the
information needed to determine the 'next step' is already there, you
just need to know how to read it. However, reading it requires a
little expertise and familiarity with the system.

A combination of Trac queries that can pull out tickets that need
attention, and an autogenerated text summary that clearly describes
the action required sounds like a valuable addition (i.e., distill the
Trac flags into a text statement of "This ticket needs external
review" or "This ticket isn't complete -- it's missing tests and/or
docs").

> Are only critical tickets eligible for a vote? I think there are a lot
> of non-critical (even trivial) tickets that are stuck in DDN hell :)
> Maybe we could organise regular DDN and Ready for checkin triage
> sprints?
>
> Also as DDN tickets must be decided by core committers, the community
> and patch authors can't really do anything with these tickets and they
> are stick in limbo. Perhaps there needs to be another flag to indicate
> whether the core committers need more information or a proposal for
> why a ticket should be included before they can make their decision,
> or if it has been added to the queue of tickets to be decided on
> (maybe with a position in the queue), and make sure that the queue is
> worked through in order, and either sent back to the patch author for
> more information or put to a vote if a decision can't be made?

As a general principle, DDN 

Re: variable view name in url tag

2010-10-04 Thread Russell Keith-Magee
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 %}, {% url
> edit-profile profile.pk %}
>
> Variable access is done via a "var=" first argument: {% url
> var=some_urlname %} , {% url var=client.edit_profile_urlname
> profile.pk %}

I don't deny that this would be backwards compatible. However, rather
than work around a syntactic wart, I'd rather fix it outright. {% load
future_urls %} gives us an 18 month window (or so) during which; 36
months if we replace future_urls with old_urls when we do the
switchover.

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-develop...@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: ANN: Improving our decision-making and committer process

2010-10-04 Thread Tai Lee
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 to edit this page. Other wiki pages have an "Edit this
page" and "Attach file" buttons at the bottom, but not the Reports
page.

I was just going to add a link to tickets that are Accepted with a
patch that doesn't need docs, tests or improvement as tickets that
just need a fresh pair of eyes to review and either bump up to Ready
for checkin or back down to Patch needs improvement (with feedback).

I also noticed that 3 of the 4 existing links under "Tickets needing
some work" are incorrect. They indicate that they are accepted
tickets, but only one of these links is filtering by triage stage.

> Work on (2) began at some point over 
> athttp://code.djangoproject.com/wiki/TicketChangeHelp. It's pretty rough
> still, but once it gets better I'd love to link sections from the
> ticket page and/or move it into the docs directly.

This is good, but it looks like mostly copy and paste from the
"Contributing to Django" docs (duplication of data, also the Wiki is
not authoritative, especially when not authored by a core committer)
for the descriptions of each triage stage and patch flag, with the
addition of next steps. I'm also not sure if this Wiki page is linked
to from anywhere (e.g. actual ticket pages)?

Perhaps we'd be better off simply adding the next steps information to
the "Contributing to Django" docs directly, and to also update the
diagram there to include the various patch flags (has patch, needs
docs, needs tests, patch needs improvement) between the Accepted and
Ready for checkin triage stages?

At the moment all the docs / diagram say is that tickets which have a
patch with docs and tests are moved to ready for checkin, but a quick
search on trac revealed 358 tickets with this combination of triage
stage and patch flags. These tickets should all be either "patch needs
improvement" with feedback, or ready for checkin, right?

Perhaps we need another triage stage for these tickets, "Needs final
review" or something?

This is where I personally feel one of the big problems is with
perceived responsiveness of the core committers. These tickets are
sitting there as Accepted, and don't appear to require any further
action from the community or patch author (don't need a patch, docs,
tests or improved patch), and they are ignored by people wanting to
contribute and core committers alike.

> Ideally, I'd like each ticket page to have a "what's next?" box on it
> indicating where the ticket is and how to move it along. Technically
> this isn't hard -- we've got plenty of folks in our community who
> could write a Trac plugin -- but getting the language right is
> important. If we get that worked out to some extent I'll figure out
> what the next steps are technically.

Perhaps another boolean flag that simply says if the next step lies
with the patch author / community, or with the core committers?
Similar to regular support tickets which might say "waiting on
customer" or "waiting on support staff". This could help avoid
situations where the patch author thinks they've done everything they
need to do, satisfied all the requirements (docs, tests, code style),
and yet their ticket is never pushed up to Ready for checkin, which
only makes them less likely to contribute again in future and more
likely to simply fix or work around their problem locally instead and
save writing docs and tests for Django that go unused.

> For (3), well, feel free to bring things up here or on IRC, I s'pose.
> I'd really appreciate it if we didn't get 'em all brought up at once,
> of course. But yes, if there are tickets marked DDN that you feel are
> critical, please feel free to ask for a yay/nay.

Are only critical tickets eligible for a vote? I think there are a lot
of non-critical (even trivial) tickets that are stuck in DDN hell :)
Maybe we could organise regular DDN and Ready for checkin triage
sprints?

Also as DDN tickets must be decided by core committers, the community
and patch authors can't really do anything with these tickets and they
are stick in limbo. Perhaps there needs to be another flag to indicate
whether the core committers need more information or a proposal for
why a ticket should be included before they can make their decision,
or if it has been added to the queue of tickets to be decided on
(maybe with a position in the queue), and make sure that the queue is
worked through in order, and either sent back to the patch author for
more information or put to a vote if a decision can't be made?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email 

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

2010-10-04 Thread Cesar Canassa
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 with Django internals so I
don't fell very confident in reviewing it myself.

I will be more than happy in writing tests or improving the patch if
the reviewer find it to be required!

Thanks!
Cesar Canassa

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: reset and sqlreset - PendingDeprecationWarning

2010-10-04 Thread Russell Keith-Magee
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
> django/core/management/sql.py to raise the appropriate warning.
>
> What message should I displayed ? I have the following right now:
> "This command is pending deprecation." I know it is not really
> insightful. The real reason is that those commands don't work well but
> I don't think we want to have that as the message.

Something short and pithy is all you need. There are a couple of
existing PendingDeprecationWarnings in Django's code already; use
those as a guide for appropriate style.

Don't get too concerned about getting the text completely perfect,
though; a core committer will probably give the text a polish before
they commit.

> I guess I also need to update docs/releases/1.3.txt with an
> explanation on why deprecation is pending.

Correct. Again, don't get too concerned about the exact text --
documentation is almost *always* polished before committing.

> Finally, do I need to update the following files with the warning
> information.
> docs/ref/django-admin.txt
> docs/man/django-admin.1

Yes. In ref/django-admin.txt, you can use a Sphinx annotation to
declare the deprecated feature:

.. deprecated:: 1.3

There are a couple of other uses of this in the docs, so search around
for examples of usage. You might also want to do a quick audit of
django-admin.1 to check that we actually have all the builtin admin
commands... I have a sneaking suspicion there might be a couple
missing.

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-develop...@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: variable view name in url tag

2010-10-04 Thread SmileyChris
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 argument: {% url
var=some_urlname %} , {% url var=client.edit_profile_urlname
profile.pk %}

On Oct 5, 5: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:
>
> > > 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 know this has come up over the last few years[1] and people are
> > >>> mixed on the action that should be taken. I would like to bring it up
> > >>> again as it has bitten me a few time lately.
>
> > >>> I seems the biggest concern is backwards compatibility of the syntax.
> > >>> I feel that should not stop us from fixing something that is an
> > >>> annoying wart and also keeping the syntax in line with how other tags
> > >>> work.
>
> > >>> In this thread[2] Malcolm suggested introducing a new tag and
> > >>> depreciating the old one which could be done by bringing something
> > >>> like[3] into core. Im not huge on the idea of have 2 tags that do the
> > >>> same thing only with slightly different syntax, but if that is the
> > >>> cleanest upgrade I'm +1.
>
> > >>> I think this can still be done in a backwards compatible way[4],
> > >>> unless I'm missing something.
>
> > >> This isn't backwards compatible in every case. Consider:
>
> > >> {% url foo %}
>
> > >> foo could be:
> > >> - A URL pattern name
> > >> - A variable in the context
> > >> - A variable in the context *and* a URL pattern name
>
> > >> It's the third case where your proposal has problems. Under the
> > >> current implementation, it's *always* interpreted as a URL pattern
> > >> name. Under your proposal, the context variable would take precedence
> > >> in the third case.
>
> > >> It's also backwards incompatible in the second case (though not in a
> > >> way that matters as much): if you have an existing template that
> > >> raises an error, but you have a context variable that matches the name
> > >> you've used, your implementation *won't* raise an error.
>
> > >> However, there is another way (an alternative to adding a parallel tag) 
> > >> :-)
>
> > >> An interesting quirk/feature of Django's template language: if you
> > >> register template tags with the same name, the last registered name
> > >> wins.
>
> > >> This means we can define a "future_url" template tag library that
> > >> registers a {% url %} template tag. Then, in your code, you can say:
>
> > >> {% load future_url %}
> > >> {% url "url-name" foo=bar %}
>
> > >> and get the new behavior. Then, we can put PendingDeprecationWarnings
> > >> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> > >> in 1.4. Then, in 1.5, we switch the behavior over and start
> > >> deprecating the future_url tag library.
>
> > >> I'm completely in favor of making this change; the behavior of the url
> > >> tag has always been an annoying wart, and it would be good to clean it
> > >> up.
>
> > >> Yours,
> > >> Russ Magee %-)
>
> > > Thanks for the feedback Russ. I know it couldn't be that straight 
> > > forward. I'll work on a patch this week that
> > > implements what you mentioned. Would it be best to start a new ticket or 
> > > re-open the old ticket?
>
> > Open a new ticket. #7917 proposes fixing the existing tag; this is a
> > complete new approach to the problem. However, make sure you reference
> > the old ticket and discussions so we have a point of reference. Feel
> > free to accept the new ticket for the 1.3 milestone.
>
> Okay I created a new ticket with patch for 
> this.http://code.djangoproject.com/ticket/14389
>
>
>
>
>
>
>
> > 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-develop...@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: variable view name in url tag

2010-10-04 Thread Russell Keith-Magee



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 
forward. I'll work on a patch this week that > implements what you mentioned. 
Would it be best to start a new ticket or re-open the old ticket? Open a new 
ticket. #7917 proposes fixing the existing tag; this is a complete new approach 
to the problem. However, make sure you reference the old ticket and discussions 
so we have a point of reference. Feel free to accept the new ticket for the 1.3 
milestone..s...@gmail.com>.s...@gmail.com>Okay I created a new ticket with 
patch for this.http://code.djangoproject.com/ticket/14389Thanks Sean. I've put 
this on my todo list once I've sorted out major features for the alpha.If 
you're in the area and you're feeling particularly enthused, it would be a nice 
idea to do an audit of all the other Django template tags to see if there are 
any other tags
 that need a similar migration plan. For example, I think #9666 describes the 
asme problem, but with the {% ssi %} tag. I can't think of any other examples 
off the top of my head, but it wouldn't surprise me if they exist.If we're 
going to introduce a "from future" analog for template tags, it would be nice 
to get *all* the things that need to come from the future.
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-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread George Sakkis
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:
>
> >  if isinstance(view, type) and issubclass(view, View):
> >      view = view.dispatch
>
> Russ mentioned this one can't be decorated.

What does "this" refer to here ? It's just a shortcut for the common
case, you can always decorate the SomeClassView.dispatch:

url("^articles1/$", ArticlesView.dispatch), #
undecorated
url("^articles2/$", login_required(ArticlesView.dispatch)), #
decorated

url("^articles3/$", ArticlesView),   # shortcut of the
first
# url("^articles4/$", login_required(ArticlesView)), # this doesn't
work

There is an asymmetry here but that's not to say it can't be
decorated, you just have to decorate the dispatch method instead of
the class view.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.



Site app should be able to make absolute URLs #10944

2010-10-04 Thread Laurent Luce
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 names. Better naming
is welcome.

Can someone review the patch?

I will work on the documentation changes when I get more feedback.

Laurent Luce

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Marco Chomut
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 your route a url to a View class it really
shouldn't be an issue.

My apologies if it has already been brought up, but I'd also like to
propose that a default context_instance be added as a self variable to
the View class, if for nothing else than to avoid having to write
context_instance=RequestContext(request) in nearly every return
statement, or requiring every one of my apps to be dependent on
something like django-annoying for its render_to() decorator.

On Oct 4, 3:21 pm, George Sakkis  wrote:
> 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
> > > results in some other class, why not simply go with a more explicit
> > > classmethod.  Simply used as:
>
> > > url("^articles/$", ArticlesView.dispatch).
>
> > Interesting. So `View.dispatch` would look something like:
>
> >     @classmethod
> >     def dispatch(cls, request, *args, **kwargs):
> >         instance = cls()
> >         callback = getattr(instance, request.method.lower())
> >         return callback(request, *args, **kwargs)
>
> > (e.g. create an instance of `cls` then call `get`/`post`/etc. on it).
>
> > Other than the slight cruftyness of `dispatch`, I quite like it. Seems
>
> 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
>
> > it addresses most of the issues we've found so far. Doesn't solve the
> > "pass configuration into __init__" idea, but frankly I didn't think
> > much of that idea in the first place.
>
> Luke's View.configure(**kwargs) classmethod takes care of that too.
>
> George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread David P. Novakovic
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

Russ mentioned this one can't be decorated.

I personally love the classmethod idea, so that's +1 from me for that.

D

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread George Sakkis
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 it:
>
> url(r'^detail/author/(?P\d+)/$',
>         views.AuthorDetail.as_view(some_param=123),
>         name="author_detail"),
>
> It returns a newly created view function, which in turn calls your
> class.
>
> http://bitbucket.org/spookylukey/django-class-views-experiments/src/t...

It seems there is a corollary to D. Wheeler's quote: "all problems in
computer science can be solved by another level of nested
closures" ;-)

> This was, in fact, suggested by Jari Pennanen in May :-(
>
> http://groups.google.com/group/django-developers/msg/997ac5d38a96a27b
>
> It's slightly less verbose for passing parameters, as you don't need a
> separate 'configure' call.

Indeed, although it's very slightly more verbose for the (common) case
that you don't want to pass parameters: views.AuthorDetail.as_view().

Unless we "cheat" and have the resolver do:

  if isinstance(view, type) and issubclass(view, View):
  # or perhaps if it quacks like a View
  # if hasattr(view, 'as_view'):
  view = view.as_view()

in which case it can be declared in the urlconf simply as
views.AuthorDetail.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread George Sakkis
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
> > results in some other class, why not simply go with a more explicit
> > classmethod.  Simply used as:
>
> > url("^articles/$", ArticlesView.dispatch).
>
> Interesting. So `View.dispatch` would look something like:
>
>     @classmethod
>     def dispatch(cls, request, *args, **kwargs):
>         instance = cls()
>         callback = getattr(instance, request.method.lower())
>         return callback(request, *args, **kwargs)
>
> (e.g. create an instance of `cls` then call `get`/`post`/etc. on it).
>
> Other than the slight cruftyness of `dispatch`, I quite like it. Seems

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

> it addresses most of the issues we've found so far. Doesn't solve the
> "pass configuration into __init__" idea, but frankly I didn't think
> much of that idea in the first place.

Luke's View.configure(**kwargs) classmethod takes care of that too.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Luke Plant
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+)/$',
views.AuthorDetail.as_view(some_param=123),
name="author_detail"),

It returns a newly created view function, which in turn calls your
class.

http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/classmethod2.py

This was, in fact, suggested by Jari Pennanen in May :-(

http://groups.google.com/group/django-developers/msg/997ac5d38a96a27b

It's slightly less verbose for passing parameters, as you don't need a
separate 'configure' call.

Luke

-- 
"Doubt: In the battle between you and the world, bet on the world." 
(despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.



reset and sqlreset - PendingDeprecationWarning

2010-10-04 Thread Laurent Luce
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 have the following right now:
"This command is pending deprecation." I know it is not really
insightful. The real reason is that those commands don't work well but
I don't think we want to have that as the message.

I guess I also need to update docs/releases/1.3.txt with an
explanation on why deprecation is pending.

Finally, do I need to update the following files with the warning
information.
docs/ref/django-admin.txt
docs/man/django-admin.1

Laurent Luce

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Łukasz Rekucki
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 class, why not simply go with a more explicit
>> classmethod.  Simply used as:
>>
>> url("^articles/$", ArticlesView.dispatch).
>>
>> It seems to address all concerns: it's explicit, safe to assign
>> attributes, Pythonic, and fails loudly if used improperly (using
>> AritlcesView would result in an Exception being throw since it doesn't
>> return an HttpResponse, and using, and ArticlesView() an error about
>> not being callable).
>
> After playing around with this for a bit, it seems to be the best option
> on the table.  The only slight API problem I've come across is that it
> is *possible* to try to pass configuration arguments to __init__:
>
>  class MyView(View):
>     def __init__(self, myparam=0):
>         ...
>
>  view = MyView(myparam=1).as_view
>
> instead of using configure:
>
>  view = MyView.configure(myparam=1).as_view
>
> However, as soon as you try to use that view, you will find that your
> custom parameter is being ignored.  That might cause some head
> scratching to the newbie, but nothing like the insidious thread-safety
> problems we're trying to avoid.

At the risk of being silly again, this can be prevented by a decorator:

class classonlymethod(classmethod):
def __get__(self, instance, owner):
if instance is not None:
raise AttributeError("This method is availble only on the
view class.")
return super(classonlymethod, self).__get__(instance, owner)

Of course, subclasses that want to override as_view() would need to
use the same decorator (classmethod will still work, just won't catch
the error).




>
> Luke
>
>
> --
> "Doubt: In the battle between you and the world, bet on the world."
> (despair.com)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>



-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Luke Plant
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:
> 
> url("^articles/$", ArticlesView.dispatch).
> 
> It seems to address all concerns: it's explicit, safe to assign
> attributes, Pythonic, and fails loudly if used improperly (using
> AritlcesView would result in an Exception being throw since it doesn't
> return an HttpResponse, and using, and ArticlesView() an error about
> not being callable).

After playing around with this for a bit, it seems to be the best option
on the table.  The only slight API problem I've come across is that it
is *possible* to try to pass configuration arguments to __init__:

  class MyView(View):
 def __init__(self, myparam=0):
 ...

  view = MyView(myparam=1).as_view

instead of using configure:

  view = MyView.configure(myparam=1).as_view

However, as soon as you try to use that view, you will find that your
custom parameter is being ignored.  That might cause some head
scratching to the newbie, but nothing like the insidious thread-safety
problems we're trying to avoid.

Luke


-- 
"Doubt: In the battle between you and the world, bet on the world." 
(despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Luke Plant
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:

http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/classmethod.py#cl-40

(I have 'as_view' instead of 'dispatch').  My MyView.dispatch method
could have decorators applied inside the actual class (as long as they
are adjusted for being method decorators and not function decorators, in
common with all other solutions).

Luke

-- 
"Doubt: In the battle between you and the world, bet on the world." 
(despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Łukasz Rekucki
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
>> results in some other class, why not simply go with a more explicit
>> classmethod.  Simply used as:
>>
>> url("^articles/$", ArticlesView.dispatch).
>
> Interesting. So `View.dispatch` would look something like:
>
>   �...@classmethod
>    def dispatch(cls, request, *args, **kwargs):
>        instance = cls()
>        callback = getattr(instance, request.method.lower())
>        return callback(request, *args, **kwargs)
>
> (e.g. create an instance of `cls` then call `get`/`post`/etc. on it).
>
> Other than the slight cruftyness of `dispatch`, I quite like it. Seems
> it addresses most of the issues we've found so far. Doesn't solve the
> "pass configuration into __init__" idea, but frankly I didn't think
> much of that idea in the first place.
>
> To my eyes this is the best solution raised so far.
>

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.

-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Luke Plant
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:
> 
> url("^articles/$", ArticlesView.dispatch).
> 
> It seems to address all concerns: it's explicit, safe to assign
> attributes, Pythonic, and fails loudly if used improperly (using
> AritlcesView would result in an Exception being throw since it doesn't
> return an HttpResponse, and using, and ArticlesView() an error about
> not being callable).
> 
> Last idea, I swear,
> Alex
> 

I've put together a repos with a bunch of scripts that demonstrate in
about a page of code the essence of what we are trying to achieve
(without all the detail about the actual dispatch to HTTP verbs etc).
Start with naive.py:

http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/naive.py

(Just run as 'python naive.py' to see the output). Browse up a level to
see the other variants.

I implemented Alex's latest idea in classmethod.py (with 'as_view'
instead of 'dispatch', to avoid name clashes).  It suffers from the same
limitation as the __new__ in that you can't pass configuration data to
the init.  But you can do a 'configure' class method, as you can also do
with __new__

Personally, I now prefer these: first place:

http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/classmethod.py

Close second:

http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/magicnew_with_configure.py

Given the limitations, I'm no longer that bothered about the fact that
the __new__ method returns something completely unexpected, but Alex's
classmethod solution seems like a nice improvement on it, though it
makes a URLconf very slightly more verbose.

Luke


-- 
"Doubt: In the battle between you and the world, bet on the world." 
(despair.com)

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Contributing more

2010-10-04 Thread Laurent Luce
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 contribute more code wise. I looked at the tickets with
> > milestone 1.3 and with no patch. It is hard to know what is critical
> > and where help is the most needed.
>
> > Can someone tell me what tickets require immediate help and are not
> > too complicated for a new contributor. I don't mind spending 2-3 days
> > before Oct 18th. I have been using Django for 2 years and I am quite
> > familiar with the basics like views, models, templates and forms.
>
> > Please let me know.
>
> First of all -- thanks for offering to help out!
>
> Unfortunately, there is no simple answer to the "what is critical" question.
>
> We try to ship Django releases that don't contain any bugs that cause
> unexpected data-loss or major system crashes at runtime -- they're the
> only type of bug that we genuinely consider critical, and we postpone
> releases if anyone reports them. So, there *shouldn't* be any of those
> bugs in our system.
>
> Beyond that, it's difficult to point you at a list of "important
> tickets". Anything that is currently open is a candidate for being
> closed; the tickets that get closed are the ones that people actively
> pursue to completion.
>
> So - what should you do? Well, here's the general list of tasks that
> need attention:
>
>  * Any ticket in the unreviewed state [1] needs to be verified. See if
> you can reproduce the problem described. If you can, move the ticket
> to Accepted. If you can't, close the ticket. If you think there is a
> major design issue in question, move to Design Decision Needed. Ask
> around on IRC if you need guidance on how to treat a given ticket. If,
> in the process of verifying the problem, you can construct a test case
> that is integrated with Django's own test suite, you get bonus points;
> upload a patch containing the test when you mark the ticket accepted.
>
>  * Any ticket in the accepted state that doesn't already have a patch
> [2], needs a patch. Try your hand at fixing the problem.
>
>  * Any ticket in the accepted state that has a patch, but isn't marked
> "needs docs", "needs tests" or "needs improvement" [3] probably needs
> a review by someone. Review the patch; if it seems like the right fix
> for the problem, and it has tests and docs (as required), move it to
> RFC.
>
>  * Any ticket in the accepted state that *is* marked "needs docs" [4],
> "needs tests" [5] or "needs improvement" [6] indicates that there is
> work to be done. Fix the problem, drop the flag.
>
> [1]http://code.djangoproject.com/query?status=new=assigned...
>
> [2]http://code.djangoproject.com/query?status=new=assigned...
>
> [3]http://code.djangoproject.com/query?status=new=assigned...
>
> [4]http://code.djangoproject.com/query?status=new=assigned...
>
> [5]http://code.djangoproject.com/query?status=new=assigned...
>
> [6]http://code.djangoproject.com/query?status=new=assigned...
>
> These queries reveal some pretty long ticket lists, which still leaves
> the issue of which one to pick.
>
> [2]-[6] can be filtered by milestone, which will reduce the ticket
> count a little; the milestone isn't a guaranteed marker that an issue
> is important, but it usually means that *someone* thinks it is
> important.
>
> Any ticket with lots of discussion, or a long CC list probably
> indicates that there are lot of people interested. This is also a
> reasonable indication that a ticket is worth looking into.
>
> Other than that -- work on whatever interests you. Pick a component
> where you feel comfortable, and use that component to filter the Trac
> queries I gave.
>
> As for the October 18th deadline -- that's a deadline for major
> feature inclusion. For 1.3, this is looking like #12012, #12991, and
> maybe #6735 and #12323. If you want to help out with these tickets,
> test the candidate patches, and check the mailing lists for any recent
> discussions about issues still needing resolution.
>
> After that date, focus will move to smaller features and bug fixes
> until the end of November. Past that date, we will move to focussing
> on purely bug fixes until the release early in the new year.
>
> 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-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Jacob Kaplan-Moss
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
> classmethod.  Simply used as:
>
> url("^articles/$", ArticlesView.dispatch).

Interesting. So `View.dispatch` would look something like:

@classmethod
def dispatch(cls, request, *args, **kwargs):
instance = cls()
callback = getattr(instance, request.method.lower())
return callback(request, *args, **kwargs)

(e.g. create an instance of `cls` then call `get`/`post`/etc. on it).

Other than the slight cruftyness of `dispatch`, I quite like it. Seems
it addresses most of the issues we've found so far. Doesn't solve the
"pass configuration into __init__" idea, but frankly I didn't think
much of that idea in the first place.

To my eyes this is the best solution raised so far.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Alex Gaynor
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 rendering), and do it early
>> on, at a high level, inside dispatch().  Instead of expecting the
>> ListView.GET to return an HTTPResponse, for example, have it return a
>> context or a context dictionary that could be reused with several
>> render_result() implementations.
>>
>
> This is problematic if I want to return something that isn't a context, or
> like it (for example, if I'm rendering images, or fetching content wholesale
> out of a database).
>
>>   * Second, have the dispatch method in View call
>> render_result(context_dict), which will raise a NotImplemented
>> exception in the base class, but will return in the subclass whatever
>> the return data might be.  This will be the locus of control for
>> different data implementations, and can largely be implemented without
>> any knowledge of the data processing details.
>>   * Third, provide different implementations of render_result()
>> through the use of different mixins, each targeting a different output
>> style (template, json, XML, PDF, etc.).  That way, the logic that
>> handles data processing and retrieval can be re-used regardless of
>> what the data output may be, and vice-versa.
>>   * Finally, handle redirects, reloads, or 404's through exceptions,
>> which would be processed inside dispatch() as well.  Using exceptions
>> for normal flow of control is generally frowned upon, but here it
>> would allow for a simplified API description for calls to GET(),
>> POST(), etc.: These methods would return a dictionary in the standard
>> case, and raise specialized exceptions for redirects, reloads, or file-
>> not-founds and other deviations from the "norm."
>>
>> The current implementation is already using mixins in order to
>> maximize code reuse in form processing.  It seems that using mixins to
>> modify rendering behavior would also be appropriate.   And if mixins
>> are unacceptable for the documented API ("mixins are a relatively
>> unused part of Python, and multiple inheritance can cause some odd
>> bugs"), the same compartmentalization can be achieved, albeit in a
>> more repetitive way (copy and paste), by simply overriding
>> render_result(context_dict) in direct subclasses of ListView,
>> DetailView, etc.  Most significantly, however, it would be much easier
>> to document how a user can add his or her own response data type if
>> such a thing were limited to nothing more than overriding
>> render_result(context_dict).
>>
>> Of course this is just one example of an approach.  There are other
>> approaches that would also be an improvement over what is implemented.
>>
>
> So, bfirsh's previous iteration had content formats built into the base
> class - I ripped it out and replaced it with a simpler base class, and he
> seemed to agree, so that's where we currently are.
>
> My main concern is getting rid of the simplicity - e.g. of calling render()
> on a template/context mix. In this aforementioned previous iteration, if I
> wanted to supply custom context to a custom template, I had to override both
> self.get_template_name() and self.get_context() - even though it would have
> been a lot easier to override GET and just call self.render(). It's a
> similar problem to passing everything around as keyword arguments -
> reusability doesn't turn out to be much better than starting from scratch.
>
> (FWIW, I've written several hundred LOC with both styles and it was a lot
> less work when there was less abstraction)
>
> I just don't want us to build in all these abstraction layers and have the
> ability to customise everything perfectly but in a verbose fashion. That
> said, if render_result() in your example just calls a normal render() method
> itself, it's easy to not use it if you don't have to, so a reasonable
> approach to get both of these angles in is possible.
>
> Also, what use cases do people have for returning arbitary pages as JSON or
> XML?
> I'm not saying there aren't any - far from it - but I much prefer evidence
> to speculation, so some concrete examples would be great
>
> Finally, we have to be wary of making this automatic on all views, or
> something similar - it could potentially be a security/warm-fuzzy-feeling
> risk, as some people put things into the context that aren't necessarily for
> display to the user (though you'd have to be pretty stupid to put anything
> actually sensitive in there).
>
> (There's also the issue of whether you apply context processors to the JSON
> replies, and so forth, but that's going even further down the rabbit hole)
>
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to 

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

2010-10-04 Thread legutierr
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 we've got that sorted out, Ben's patch is feature complete and
> shouldn't be too hard to adapt to any base class along the lines of
> what we've been describing.

Given that most of this thread has been dedicated to simply discussing
"how to architect the base class", I think that there is an
opportunity to discuss other elements of the implementation that have
been neglected up to now.

While bfirsh's implementation may be *almost* feature complete, it
seems to be lacking one major feature that will be important to many,
if not most, users; specifically, the ability to easily return data
*other than* html rendered from a template.  A large number of users,
if not a majority, will want to be able to use class-based views to
return JSON data.  Others will want to render and return XML or PDF
data.  Some users may even want to use django-annoying's @render_to
and @ajax_request decorators, and would have classy views return
dictionaries instead of HTTPResponse objects.

Of course, users could subclass the base View class to do any of these
things, but then they would be discarding most of this module's useful
functionality.  The real power of class-based generic views will be
found in the subclasses included in the module (ListView, DetailView,
etc.).  The real power will be the ability to re-use the generic list-
processing, detail-processing, and form-processing code, not in the
high-level architecture of the base class.

Users, I think, should be shown an obvious and intuitive path by which
they may reuse the data-processing logic of these generic view objects
without being limited to a single output format, and without having to
jump through hoops in terms of subclassing disparate objects and
overriding tricky methods that differ from subclass to subclass in
terms of both signature and implementation.

At this moment in time, TemplateView is a base class of all of View's
descendant classes in bfirsh's implementation.  All inheritance flows
through TemplateView for the entire library.  Furthermore, every data-
processing subclass of View references TemplateView's
render_to_response method, which is oriented in its implementation and
(more importantly) its signature only towards template processing.

As a result, any user wanting to implement a JsonView, an XMLView, or
a PDFView will need to subclass a subclass of TemplateView in order to
reuse the generic views' data-processing code, and will also have to
know quite a bit about the intricacies of how the different methods
interact inside each of these classes.  This sub-optimal for a number
of reasons:
  1. Views that neither render html nor use templates will report that
they are TemplateView instances (via isinstance()).
  2. In order to create a suite of generic JsonViews, for example,
many different classes will have to be subclassed, and the methods
that are overridden will not be consistent across those subclasses.
  3. It is unlikely that any of this will be documented, and the
overriding rules will not be intuitive nor obvious, leading to
confusion and support requests.

A moderate refactoring of the internals of the implementation, along
with a willingness to see some of the lower-level implementation
details of the generic view objects as part of the public API, could
resolve these issues.  My own suggestion is as follows:

  * 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 rendering), and do it early
on, at a high level, inside dispatch().  Instead of expecting the
ListView.GET to return an HTTPResponse, for example, have it return a
context or a context dictionary that could be reused with several
render_result() implementations.
  * Second, have the dispatch method in View call
render_result(context_dict), which will raise a NotImplemented
exception in the base class, but will return in the subclass whatever
the return data might be.  This will be the locus of control for
different data implementations, and can largely be implemented without
any knowledge of the data processing details.
  * Third, provide different implementations of render_result()
through the use of different mixins, each targeting a different output
style (template, json, XML, PDF, etc.).  That way, the logic that
handles data processing and retrieval can be re-used regardless of
what the data output may be, and vice-versa.
  * Finally, handle redirects, reloads, or 404's through exceptions,
which would be processed inside dispatch() as well.  Using exceptions
for normal flow of control is generally frowned upon, but here it
would allow for a simplified API 

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

2010-10-04 Thread Warren Smith
>
> 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 set of
> generic views with and without state like this).
>
>>
> I personally think self is the place to store this state (since, as Russ
> keeps saying, that's how nearly all Python classes do it), but storing it on
> request isn't too bad - it just "feels" more wrong to me, but then,
> middleware does it already.
>
>
I haven't picked up the brush/spraycan yet, preferring instead to allow
those smarter than me to decide the color scheme for this particular bike
shed.  :-)

>
Seriously though, the key considerations and points made in this thread need
to be extracted and put somewhere in the django docs, preferably in a place
that doesn't distract a brand new user but also gets read soon after they
complete the tutorial and begin digging a little deeper.  Knowing the design
considerations that went into whatever path is taken is, IMHO, invaluable.

>
I am willing to do the work to make that happen if nobody else is
interested.  I have not yet contributed to the corpus of django
documentation, but perhaps this an opportunity to do so.

>

>  However, subjectivity isn't going to win through here. Either solution is
> fine, just don't force me to pass everything around as arguments between
> functions. That's not looking likely, but some people here seen to want to
> have that kind of purity at the expense of usability - dammit, Jim, I'm an
> engineer, not a mathematician.
>
>
+1

-- 
Warren Smith

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: variable view name in url tag

2010-10-04 Thread Sean Brant


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 know this has come up over the last few years[1] and people are
> >>> mixed on the action that should be taken. I would like to bring it up
> >>> again as it has bitten me a few time lately.
>
> >>> I seems the biggest concern is backwards compatibility of the syntax.
> >>> I feel that should not stop us from fixing something that is an
> >>> annoying wart and also keeping the syntax in line with how other tags
> >>> work.
>
> >>> In this thread[2] Malcolm suggested introducing a new tag and
> >>> depreciating the old one which could be done by bringing something
> >>> like[3] into core. Im not huge on the idea of have 2 tags that do the
> >>> same thing only with slightly different syntax, but if that is the
> >>> cleanest upgrade I'm +1.
>
> >>> I think this can still be done in a backwards compatible way[4],
> >>> unless I'm missing something.
>
> >> This isn't backwards compatible in every case. Consider:
>
> >> {% url foo %}
>
> >> foo could be:
> >> - A URL pattern name
> >> - A variable in the context
> >> - A variable in the context *and* a URL pattern name
>
> >> It's the third case where your proposal has problems. Under the
> >> current implementation, it's *always* interpreted as a URL pattern
> >> name. Under your proposal, the context variable would take precedence
> >> in the third case.
>
> >> It's also backwards incompatible in the second case (though not in a
> >> way that matters as much): if you have an existing template that
> >> raises an error, but you have a context variable that matches the name
> >> you've used, your implementation *won't* raise an error.
>
> >> However, there is another way (an alternative to adding a parallel tag) :-)
>
> >> An interesting quirk/feature of Django's template language: if you
> >> register template tags with the same name, the last registered name
> >> wins.
>
> >> This means we can define a "future_url" template tag library that
> >> registers a {% url %} template tag. Then, in your code, you can say:
>
> >> {% load future_url %}
> >> {% url "url-name" foo=bar %}
>
> >> and get the new behavior. Then, we can put PendingDeprecationWarnings
> >> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> >> in 1.4. Then, in 1.5, we switch the behavior over and start
> >> deprecating the future_url tag library.
>
> >> I'm completely in favor of making this change; the behavior of the url
> >> tag has always been an annoying wart, and it would be good to clean it
> >> up.
>
> >> Yours,
> >> Russ Magee %-)
>
> > Thanks for the feedback Russ. I know it couldn't be that straight forward. 
> > I'll work on a patch this week that
> > implements what you mentioned. Would it be best to start a new ticket or 
> > re-open the old ticket?
>
> Open a new ticket. #7917 proposes fixing the existing tag; this is a
> complete new approach to the problem. However, make sure you reference
> the old ticket and discussions so we have a point of reference. Feel
> free to accept the new ticket for the 1.3 milestone.

Okay I created a new ticket with patch for this.
http://code.djangoproject.com/ticket/14389

> 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-develop...@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: rethinking raw_id_fields

2010-10-04 Thread subs...@gmail.com
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 question in the admin and
give change permissions. Also, the current resulting pop-up of a
changelist window is very displeasing to me and seems really just kind
of hacked together. Having the actions dropdown among other things
confuses things. I guess in this case one couldn't avoid registering
it in admin (or could we, and provide a default which uses the
unicode?).

2) Does anyone think there would be any advantage to 'flatten'
raw_id_fields? Essentially, it would become a non-javascript link that
would bring up a changelist which leads us back to the original
changelist and autopopulates it? Screen-reading software is rather
ambiguous when it comes to the current usability flow (aka I have had
user complaints). The problem is pretty well outlined here:
http://webaim.org/techniques/javascript/other#popups (I autocompleted
on google to find that :).

-Steve

On Oct 4, 9:56 am, Chuck Harmston  wrote:
> 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
> raw_id_fields popup is that it allows content discovery, which is an
> important use case—not all admin users will be perfectly familiar with the
> content.
>
> I am in full favor of an Ajax autocomplete widget (which, as I said, already
> exists in the admin-ui branch), but do not want it to replace raw_id_fields;
> their uses cases are completely disparate.
>
> On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com wrote:
>
>
>
>
>
> > With the AJAX field implementation on the table you're free to
> > represent the objects however you want. Yeah, there's a few things
> > left out but did you really say 'no searching'?
>
> > -Steve
>
> > On Oct 3, 10:09 pm, Chuck Harmston  wrote:
> > > it's based on the assumption that the user knows the value of the unicode
> > > representation of the object. It does not allow for discovery like the
> > > raw_id_fields popup does: no filtering, no sorting, no searching, and no
> > > browsing. I am a strong -1 this.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com > i...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> *
> Chuck Harmston
> *
> ch...@chuckharmston.comhttp://chuckharmston.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #6735 -- Class based generic views: call for comment

2010-10-04 Thread Andrew Godwin

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 subclassable views (in my own experience, having written both a set 
of generic views with and without state like this).


I personally think self is the place to store this state (since, as Russ 
keeps saying, that's how nearly all Python classes do it), but storing 
it on request isn't too bad - it just "feels" more wrong to me, but 
then, middleware does it already.


However, subjectivity isn't going to win through here. Either solution 
is fine, just don't force me to pass everything around as arguments 
between functions. That's not looking likely, but some people here seen 
to want to have that kind of purity at the expense of usability - 
dammit, Jim, I'm an engineer, not a mathematician.


Andrew

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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: rethinking raw_id_fields

2010-10-04 Thread Marcob
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
> representation of the object. It does not allow for discovery like the
> raw_id_fields popup does: no filtering, no sorting, no searching, and no
> browsing. I am a strong -1 this.

Me too. For the same exact reasons.

I usually tweak the link to open a popup already filtered and such
things.

Ciao.
Marco.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: #12991 unittest2 support - Second call for comment

2010-10-04 Thread Russell Keith-Magee

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.
> Particular attention is needed for the Oracle and GeoDjango changes,
> as I don't have the facilities to test these locally. If you have
> access to these setups and can run the suite with the patch applied,
> I'd be very grateful.
>
> [1]http://code.djangoproject.com/ticket/12991
>
> Here's a summary of the changes since last time:
>
>  * I've replaced all the checks (including the doctest checks) that
> inspected for a database backend with checks for the database feature
> that is necessary in order to pass the particular test. i.e., instead
> of just checking "backend == MySQL", the tests now checks for
> "connection.features.supports_transactions" or
> "connection.features.supports_timezones". As a result,
> DatabaseFeatures has 18 extra feature flags.
>
>  * There are three exceptions to the previous point, all contained in
> the backends regression test. These are tests for Oracle specific
> features that really are checking for Oracle specific features (cursor
> properties, NCLOB behavior, etc). To accommodate this, I've added a
> 'vendor' attribute to connection. This is a lowercase text description
> describing the vendor that has provided the database. This also allows
> us to identify the postgresql and postgresql_psycopg2 backends as
> being from the same vendor.
>
>  * As a result of the previous two points, I've been able to remove
> the skipUnlessDB and skipIfDB utilities in favor of just using the
> default unittest skipIf and skipUnless.

After some additional testing, I discovered a slight problem with this
approach. skipIf and skipUnless are evaluated at time of class load,
which is before the test database is set up, so the tests to be
skipped are determined before we know whether they can be skipped.

To counter this, I've reintroduced some custom Django skipIf/
skipUnless functions -- this time, specifically checking the name of
the database feature at runtime.
@skipUnlessDBFeature('supports_transactions') will skip a test unless
the test database supports transactions.

>  * Some database features (such as the availability of transactions)
> need to be determined at runtime. To support this, DatabaseFeatures
> has gained a 'confirm()' call. This call does the
> 'SUPPORTS_TRANSACTIONS' check, plus any other check of
> database-specific behavior that needs to be performed at runtime. At
> the moment, the only other case that requires confirmation is STDDEV,
> which may not be available depending on the version of PostgreSQL or
> the extensions loaded into SQLite. The call to confirm() is performed
> as part of the test database setup.
>
>  * The SUPPORTS_TRANSACTIONS flag has been moved out of settings, and
> into DatabaseFeatures
>
>  * In order to support confirm(), DatabaseFeatures now requires an
> argument at time of construction (the connection).
>
>  * I've rolled back the changes that rename the use of deprecated test
> methods like assertEquals, failUnless etc. It occurred to me that this
> patch is only going to be applied to trunk, not to the 1.2 branch, and
> changing the assertion syntax on a large proportion of test cases will
> make backporting tests a major pain. Normalizing test assertion usage
> is still worthwhile, IMHO; it's just something we need to do just
> before we roll 1.3, rather than right now.

As a result of extra testing I have now done myself, I'm ready to call
this an RC patch. Again, help is requested in running this test suite
on as many databases, Python versions and GIS backends as possible.

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-develop...@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: rethinking raw_id_fields

2010-10-04 Thread Chuck Harmston
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
raw_id_fields popup is that it allows content discovery, which is an
important use case—not all admin users will be perfectly familiar with the
content.

I am in full favor of an Ajax autocomplete widget (which, as I said, already
exists in the admin-ui branch), but do not want it to replace raw_id_fields;
their uses cases are completely disparate.


On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com wrote:

> With the AJAX field implementation on the table you're free to
> represent the objects however you want. Yeah, there's a few things
> left out but did you really say 'no searching'?
>
> -Steve
>
> On Oct 3, 10:09 pm, Chuck Harmston  wrote:
> > it's based on the assumption that the user knows the value of the unicode
> > representation of the object. It does not allow for discovery like the
> > raw_id_fields popup does: no filtering, no sorting, no searching, and no
> > browsing. I am a strong -1 this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>


-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Sites Framework: RequestSite and get_current

2010-10-04 Thread Gabriel Hurley
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 possible.

Thanks!

- Gabriel

On Oct 1, 4:12 am, Luke Plant  wrote:
> On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
> > I went to triage a few tickets tonight, and noticed that #8960,
> > #10235, #10608 and #13814 have all arrived at essentially the same
> > conclusion: there needs to be a single idiomatic way to get either the
> > current Site object if contrib.sites is installed, or a RequestSite
> > object if not. All four tickets use the same bit of code, the argument
> > really only lies in where to put it.
>
> > #10235 adds it as a utility function in contrib.sites.models, #13814
> > as a separate method on SiteManager, and #8960 and #10608 basically
> > just copy and paste where needed. I'm of the opinion it should have
> > its own home in contrib.sites, but where, and under what name?
>
> I think a stand-alone function in contrib.sites.models is fine, called
> `get_current_site` (or some other sensible colour of your choosing).
> Since both Site and RequestSite already live there, it seems a good
> place.
>
> Thanks for your work on this,
>
> Luke
>
> --
> "Despair: It's always darkest just before it goes pitch black."
> (despair.com)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Proposal: Meta.required_together

2010-10-04 Thread TiNo
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 real lack of patience when you spend the time writing
> what the OP has written without even reading it, just to try to
> dismiss it.
>
> OP:
>
> >def clean(self):
> >if any((self.weight, self.height))
> >if not all((self.weight, self.height))
> >raise ValidationError("Uh oh!")
>
> On Oct 3, 2:08 pm, TiNo  wrote:
> > Doesn't this do what you want?:
> >
> > class MyModel(models.Model):
> > weight = ..
> > height = ...
> > width = ...
> > length = ...
> >
> > def clean(self):
> > from django.core.exceptions import ValidationError
> > if self.weight or self.height or self.width or self.length and
> > not (self.weight and self.height and self.width and
> > self.length):
> > raise ValidationError("Sorry, in order to use weight, height,
> > width, or"
> > " length, you have to include them all.")
> >
> > def save(self, *args, **kwargs):
> > self.clean()
> > super(MyModel, self).save(*args, **kwargs)
> >
> > Of course it does require you to write a little more code, but it is
> > possible.
> >
> > Besides, does the required_together mean that all fields are required
> when
> > one is filled out, or that some are required when the first is filled
> out?
> > What I mean is that there are many possibilities for validating a model,
> and
> > at the moment we have quite some good tools for them. Adding another Meta
> > option for a small portion of the cases doesn't seem so necessary to
> me...
> >
> > Anyway, that's just my 2c.
> >
> > TinO
> >
> > On Sun, Oct 3, 2010 at 05:58, LookMa NoSQL 
> wrote:
> > > +1 on proposal (for what it matters).
> >
> > > Tina, where did you see that Django does that? The docs link you sent
> > > shows regular model validation. What Mamayo is looking for, I think,
> > > is the ability to add a Meta option to a  model that says
> > > required_together=({fields: ('weight', 'height', 'width', 'length'),
> > > error_message: "Sorry, in order to use weight, height, width, or
> > > length, you have to include them all."}). At least I think that's what
> > > he means. This would help me too.
> >
> > > On Oct 2, 10:17 am, TiNo  wrote:
> > > > Hi,
> >
> > > > Isn't this covered by model validation [1]?
> >
> > > > Tino
> >
> > > > [1]
> > >http://docs.djangoproject.com/en/dev/ref/models/instances/#validating.
> ..
> >
> > > > On Fri, Oct 1, 2010 at 15:59, hejsan  wrote:
> > > > > Hi.
> > > > > I just filed a feature request on the same or similar issue, and
> this
> > > > > thread was brought to my attention:
> > > > >http://code.djangoproject.com/ticket/14347
> >
> > > > > Basically the usecase is this:
> > > > > Very often we have a "Published" field on our models (or "Published
> > > > > date" or "Published status" etc..) It would be very nice to be able
> to
> > > > > allow people to save instances without all the required fields
> being
> > > > > filled in IF the article or whathaveyou is not published yet.
> >
> > > > > My suggestion was to allow the "required" field on the form field
> to
> > > > > take a callable instead of a boolean.
> > > > > In this callable we could check whether some other fields are
> filled
> > > > > out or whatever we want.
> >
> > > > > This would be a very handy feature for a very common problem.
> >
> > > > > best,
> > > > > Hejsan
> >
> > > > > On Sep 27, 7:34 am, Yo-Yo Ma  wrote:
> > > > > > Thanks, David. I've read some about the "Custom validation error
> on
> > > > > > unique_together" ticket. I imagine that if people want
> customization
> > > > > > there, required_together would need the same. The only idea I
> have
> > > > > > that seems to work for both situations is:
> >
> > > > > > required_together = (('weight', 'height', 'You must provide a
> weight
> > > > > > and height, if you intend to use either.'),)
> >
> > > > > > unique_together = (('account', 'sku', 'This sku is already in use
> by
> > > > > > your company.'),)
> >
> > > > > > On Sep 27, 1:22 am, "David P. Novakovic" <
> davidnovako...@gmail.com>
> > > > > > wrote:
> >
> > > > > > > Is it? I read this as different to anything in the ORM.
> >
> > > > > > > This is about conditionally requiring a second field if one is
> > > filled
> > > > > > > out. Normally it would be done at the JS level.
> >
> > > > > > > I think it's a good idea, assuming I haven't missed something
> that
> > > > > > > already does this.
> >
> > > > > > > I can't help thinking this is part of a much larger problem
> though.
> > > > > > > That problem is multifield validation. I think we'd have to
> 

Re: Sites Framework: RequestSite and get_current

2010-10-04 Thread burc...@gmail.com
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 ticket
> description:
>
> http://code.djangoproject.com/ticket/14386
>
> I'd love to get some feedback on it when possible.
>
> Thanks!
>
>    - Gabriel
>
> On Oct 1, 4:12 am, Luke Plant  wrote:
>> On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
>> > I went to triage a few tickets tonight, and noticed that #8960,
>> > #10235, #10608 and #13814 have all arrived at essentially the same
>> > conclusion: there needs to be a single idiomatic way to get either the
>> > current Site object if contrib.sites is installed, or a RequestSite
>> > object if not. All four tickets use the same bit of code, the argument
>> > really only lies in where to put it.
>>
>> > #10235 adds it as a utility function in contrib.sites.models, #13814
>> > as a separate method on SiteManager, and #8960 and #10608 basically
>> > just copy and paste where needed. I'm of the opinion it should have
>> > its own home in contrib.sites, but where, and under what name?
>>
>> I think a stand-alone function in contrib.sites.models is fine, called
>> `get_current_site` (or some other sensible colour of your choosing).
>> Since both Site and RequestSite already live there, it seems a good
>> place.
>>
>> Thanks for your work on this,
>>
>> Luke

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.