Django developers Google Group

Re: Ticket 8764 (Mixing args and **kwargs in reverse() function)

2009-01-07T01:43:09Z

Could you please be slightly less dismissive of the implementation
efforts? "Lazy", "silly", "not pythonic", "fundamental flaw" tend to
disregard the enormous efforts a number of people have put into making
that functionality work. We don't actually just make stuff up after a
few beers and commit the first thing that runs, you know. I don't think

Ticket 8764 (Mixing args and **kwargs in reverse() function)

2009-01-06T23:38:34Z

The above ticket was opened a while back concerning the inability to
define views that use both positional arguments and keyword arguments
when expecting to use reverse() to match urls tied to those views.

I don't understand the rational here for not fixing this issue. The
decision not to allow mixing args and kwargs seems like a lazy way to

Re: ticket 8764 (Mixing args and **kwargs in reverse() function)

2009-01-06T23:32:25Z

I don't understand the rational here for not fixing this issue. The
decision not to allow mixing args and kwargs seems like a lazy way to

Re: making some generic views more generic

2009-01-06T23:46:50Z

to filter the queryset appropriately and then call an existing generic
view. That's the normal approach when you need more filtering: filter
the queryset and then pass of the existing view, perhaps after also
updating extra_context. Your code seems quite long and has wrapped
fairly horribly in the email, so my eyes were watering a bit too much to

Re: making some generic views more generic

2009-01-06T23:36:10Z

Sorry, here is an example of item_list

urlpatterns = patterns('',
(r'^products/$',
item_list,{
'template_object_name' : 'product',
'queryset' : Product.objects.all()
}),
(r'^products/(?P<category__pk> \d+)/$',
item_list,{
'template_object_name' : 'product',
'queryset' : Product.objects.all()

Re: Some tickets that should perhaps get looked at before 1.1

2009-01-06T23:36:00Z

It's already being looked at. It's assigned to me for that reason. As I
mentioned in the last substantive comment on the ticket, solving it has
revealed some other problems with imports that I'm slowly working
through as time permits.
Regards,
Malcolm

Re: #3566 Aggregations: Call for testing

2009-01-06T22:45:22Z

Thanks Ian.
Russ %-)

Re: making some generic views more generic

2009-01-06T22:43:21Z

I also would like to request another view.

def item_list(request,queryset,ext ra_context={},
item_template=None,template_na me=None,
template_object_name='object', template_content_name='items',
page=None,paginate_by=None,
mimetype=None,allow_empty=True ,
template_loader=loader,context _processors=None,

Re: #3566 Aggregations: Call for testing

2009-01-06T19:19:57Z

The "ORA-00972: identifier is too long" error is caused by the column
alias names not being truncated to an acceptable length
("book__publisher__num_awards_ _min" in this case). The call to
perform the truncation is django.db.backends.util.trunca te_name(alias,
connection.ops.max_name_length ()).
The "ORA-00923: FROM keyword not found where expected" is caused by

Re: CSRF / SafeForm

2009-01-06T19:16:41Z

I added a ticket (with patch) for implementing the template tag:
[link]
It also adds a CSRF context processor, which is used by the tag.

The diff doesn't look quite right. There obviously needs to be an
empty __init__.py file added to the templatetags folder for it to

making some generic views more generic

2009-01-06T19:01:54Z

Hello,

I really like the generic view feature of Django. It's been a handy
way to save a lot of work. Lately though, I've been finding myself
often wanting to display a list of objects filtered by some field. The
documentation suggests handling this by writing a small view that
filters the objects and then calling the generic view from within

Some tickets that should perhaps get looked at before 1.1

2009-01-06T17:05:59Z

As the list seems to be resuming from holiday hibernation, I risk
causing another "don't you dare to push us" flame-bombing :) by
proposing that the following get looked at before 1.1:

* `__import__(mod, {}, {}, [''])` causes double import of modules [1]

After discussions on python-dev, an idiom emerged for a clean fix.

Re: Session-based messages (Contrib-05, #4604)

2009-01-06T16:20:44Z

I'd like to see this moved into an external app so that we can
de-couple it from the 1.1 release. If it proves to be popular and
stable, we could then consider it for 1.2.
Jacob

Re: #3566 Aggregations: Call for testing

2009-01-06T11:14:35Z

Do you have any particular fields in mind? Any custom field deriving
from the basic Django numeric and date/time types shouldn't require
any special handling, but I'd appreciate any bug report to the
contrary. If you have a use case for non numeric/date/time types, I'd
be interested to see what we can do to accomodate your needs.

Re: #3566 Aggregations: Call for testing

2009-01-06T10:55:09Z

Well the queries themselves will execute fine, and then you will just back
whatever type your database returned, you'll need to do some coercion
yourself.

Alex

--
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero