Re: required=True for BooleanFields

[David Cramer]

I'm not suggesting changing the behavior (again due to the
compatibility concerns), but I completely agree with the original
poster(s).

Also, in my experience it's a much less common case that you're
wanting an "I agree" checkbox in your form, versus a "Boolean" field
which can be positive or negative.

On Jun 16, 9:34 pm, Tai Lee  wrote:
> This has been discussed many times in the past. For better or worse,
> we're stuck with the current behaviour for backwards compatibility.
>
> I personally think it's better this way. Without this behaviour, it
> would be a PITA to implement forms that have a "required" boolean
> field (must be ticked) without repeating yourself constantly by
> writing custom validation for those fields. Most forms I work with
> have a "Yes, I have agreed to the terms and conditions" or "Yes, I
> want to receive emails from XYZ" type fields.
>
> If your boolean fields are not "required" (as per the definition in
> Django forms, "must be ticked"), why can't you just put
> `required=False` in your form?
>
> I'd try to avoid patching your local Django with a change like this
> unless absolutely necessary so that you can cleanly upgrade and don't
> end up writing code that does the opposite of what everyone else
> expects.
>
> Cheers.
> Tai.
>
> On Jun 17, 5:14 am, Michael Blume  wrote:
>
>
>
>
>
>
>
> > In Django BooleanFields, the required flag is used to mean that the field
> > must be checked for the form to validate. Required is True by default for
> > all Fields, so this is the default behavior.
>
> > I strongly suspect that this violates principle of least surprise for most
> > people including Boolean Fields in forms. It did for me.
>
> > I've patched it in my local Django checkout. I realize this is a
> > backwards-incompatible change, so it might not be eligible for trunk any
> > time soon, but FWIW, here's the patch:
>
> > --- i/django/forms/fields.py
> > +++ w/django/forms/fields.py
> > @@ -606,6 +606,11 @@ class URLField(CharField):
> >  class BooleanField(Field):
> >      widget = CheckboxInput
>
> > +    def __init__(self, *args, **kwargs):
> > +        if not args and 'required' not in kwargs:
> > +            kwargs['required'] = False
> > +        return super(BooleanField, self).__init__(*args, **kwargs)
> > +
> >      def to_python(self, value):
> >          """Returns a Python boolean object."""
> >          # Explicitly check for the string 'False', which is what a hidden
> > field

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

Re: required=True for BooleanFields

[Tai Lee]

This has been discussed many times in the past. For better or worse,
we're stuck with the current behaviour for backwards compatibility.

I personally think it's better this way. Without this behaviour, it
would be a PITA to implement forms that have a "required" boolean
field (must be ticked) without repeating yourself constantly by
writing custom validation for those fields. Most forms I work with
have a "Yes, I have agreed to the terms and conditions" or "Yes, I
want to receive emails from XYZ" type fields.

If your boolean fields are not "required" (as per the definition in
Django forms, "must be ticked"), why can't you just put
`required=False` in your form?

I'd try to avoid patching your local Django with a change like this
unless absolutely necessary so that you can cleanly upgrade and don't
end up writing code that does the opposite of what everyone else
expects.

Cheers.
Tai.


On Jun 17, 5:14 am, Michael Blume  wrote:
> In Django BooleanFields, the required flag is used to mean that the field
> must be checked for the form to validate. Required is True by default for
> all Fields, so this is the default behavior.
>
> I strongly suspect that this violates principle of least surprise for most
> people including Boolean Fields in forms. It did for me.
>
> I've patched it in my local Django checkout. I realize this is a
> backwards-incompatible change, so it might not be eligible for trunk any
> time soon, but FWIW, here's the patch:
>
> --- i/django/forms/fields.py
> +++ w/django/forms/fields.py
> @@ -606,6 +606,11 @@ class URLField(CharField):
>  class BooleanField(Field):
>      widget = CheckboxInput
>
> +    def __init__(self, *args, **kwargs):
> +        if not args and 'required' not in kwargs:
> +            kwargs['required'] = False
> +        return super(BooleanField, self).__init__(*args, **kwargs)
> +
>      def to_python(self, value):
>          """Returns a Python boolean object."""
>          # Explicitly check for the string 'False', which is what a hidden
> field

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

Re: Removal of DictCursor from raw query.. why??

[burc...@gmail.com]

Hi Cal,

Why not just put your helper to django snippets?

On Fri, Jun 17, 2011 at 12:25 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Okay, fair enough.
> At the very least, would you accept a documentation patch which would guide
> other users who come up against this same problem? Maybe it's own little
> space near the raw() stuff, which shows the example code for dictfetchall()
> but with a disclaimer saying YMMV??
> Cal
> On Thu, Jun 16, 2011 at 6:14 PM, Alex Gaynor  wrote:
>>
>>
>> On Thu, Jun 16, 2011 at 10:10 AM, Cal Leeming [Simplicity Media Ltd]
>>  wrote:
>>>
>>> In fact let me extend off this a little further.
>>> If I was to provide a code and documentation patch, which allows for an
>>> easy way to return back values with their field names (via a simple
>>> field_names=True), would you guys be willing to consider it for the core?
>>> Cal
>>>
>>> On Thu, Jun 16, 2011 at 6:07 PM, Cal Leeming [Simplicity Media Ltd]
>>>  wrote:

 @Andy / @ Alex:
 Yup, I know how to get this, but the point is, it took me 30 minutes of
 searching to find this information out.
 What I'm asking, is for consideration of an *EASY* way to get this
 format, via something like cursor.fetchall(field_names=True), or
 cursor.dictfetchall(), and for that feature to be well documented.


 On Thu, Jun 16, 2011 at 4:42 PM, Andy Dustman 
 wrote:
>
> You can do something like:
>
> for row in cursor:
>    dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
>
> (izip may be better than zip. Your call.)
>
> Or for the whole result set:
>
> result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
> for row in cursor ]
>
> On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
>  wrote:
> > Okay, let me put it another way.
> > Are there any plans to give developers an easy way to retrieve values
> > from a
> > cursor.fetchall(), in a DictCursor style?
> > Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
> > What I'm looking for:
> > [{
> >  'f1' : Decimal('0'),
> >  'f2' : Decimal('52'),
> >  'f3' : Decimal('4159'),
> >  'f4' : 9998L
> > }]
> > Maybe something like cursor.fetchall(field_names=True), or
> > cursor.dictfetchall() - which is what the removed function did.
> > Cal
> > On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant 
> > wrote:
> >>
> >> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
> >> > Okay, er.
> >> >
> >> > In reference to the original problem (cursor's not default to
> >> > DictCursor), thus no field names are returned, is there a specific
> >> > reason for this? If not, I'll probably raise a ticket to have it
> >> > considered for change.
> >>
> >> I'm not sure exactly what you are asking, because this is about
> >> default
> >> behaviour. The choice of a default is usually made according to what
> >> is
> >> thought to be the most useful, or according to the way it happens to
> >> have been done in the past.
> >>
> >> I also don't know what exactly you are suggesting. Our backwards
> >> compatibility policy means that we aren't going to change the
> >> default,
> >> unless other people's code is going to work transparently (which
> >> wouldn't be the case here), so it doesn't really matter what the
> >> original reason was, if there was one. If you are suggesting that we
> >> add
> >> some functionality to make use of DictCursor more useful, then
> >> certainly
> >> the suggestion is valid.
> >>
> >> Regards,
> >>
> >> Luke
> >>
> >> --
> >> The probability of someone watching you is proportional to the
> >> stupidity of your action.
> >>
> >> 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-developers@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/django-developers?hl=en.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups
> > "Django developers" group.
> > To post to this group, send email to
> > django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this 

Re: Template Engine Compilation and Runtime Refactoring Progress

[Armin Ronacher]

Hi,

I'm in between two conferences right now and university and a bunch of
other stuff needs attention as well so progress is slowed down quite a
bit right now.  Will however catch up next week with what I cannot do
this one.


Regards,
Armin

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

required=True for BooleanFields

[Michael Blume]

In Django BooleanFields, the required flag is used to mean that the field
must be checked for the form to validate. Required is True by default for
all Fields, so this is the default behavior.

I strongly suspect that this violates principle of least surprise for most
people including Boolean Fields in forms. It did for me.

I've patched it in my local Django checkout. I realize this is a
backwards-incompatible change, so it might not be eligible for trunk any
time soon, but FWIW, here's the patch:

--- i/django/forms/fields.py
+++ w/django/forms/fields.py
@@ -606,6 +606,11 @@ class URLField(CharField):
 class BooleanField(Field):
 widget = CheckboxInput

+def __init__(self, *args, **kwargs):
+if not args and 'required' not in kwargs:
+kwargs['required'] = False
+return super(BooleanField, self).__init__(*args, **kwargs)
+
 def to_python(self, value):
 """Returns a Python boolean object."""
 # Explicitly check for the string 'False', which is what a hidden
field

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

Re: Removal of DictCursor from raw query.. why??

[Cal Leeming [Simplicity Media Ltd]]

Okay, fair enough.

At the very least, would you accept a documentation patch which would guide
other users who come up against this same problem? Maybe it's own little
space near the raw() stuff, which shows the example code for dictfetchall()
but with a disclaimer saying YMMV??

Cal

On Thu, Jun 16, 2011 at 6:14 PM, Alex Gaynor  wrote:

>
>
> On Thu, Jun 16, 2011 at 10:10 AM, Cal Leeming [Simplicity Media Ltd] <
> cal.leem...@simplicitymedialtd.co.uk> wrote:
>
>> In fact let me extend off this a little further.
>>
>> If I was to provide a code and documentation patch, which allows for an
>> easy way to return back values with their field names (via a simple
>> field_names=True), would you guys be willing to consider it for the core?
>>
>> Cal
>>
>>
>> On Thu, Jun 16, 2011 at 6:07 PM, Cal Leeming [Simplicity Media Ltd] <
>> cal.leem...@simplicitymedialtd.co.uk> wrote:
>>
>>> @Andy / @ Alex:
>>>
>>> Yup, I know how to get this, but the point is, it took me 30 minutes of
>>> searching to find this information out.
>>>
>>> What I'm asking, is for consideration of an *EASY* way to get this
>>> format, via something like cursor.fetchall(field_names=True), or
>>> cursor.dictfetchall(), and for that feature to be well documented.
>>>
>>>
>>>
>>> On Thu, Jun 16, 2011 at 4:42 PM, Andy Dustman wrote:
>>>
 You can do something like:

 for row in cursor:
dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )

 (izip may be better than zip. Your call.)

 Or for the whole result set:

 result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
 for row in cursor ]

 On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
  wrote:
 > Okay, let me put it another way.
 > Are there any plans to give developers an easy way to retrieve values
 from a
 > cursor.fetchall(), in a DictCursor style?
 > Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
 > What I'm looking for:
 > [{
 >  'f1' : Decimal('0'),
 >  'f2' : Decimal('52'),
 >  'f3' : Decimal('4159'),
 >  'f4' : 9998L
 > }]
 > Maybe something like cursor.fetchall(field_names=True), or
 > cursor.dictfetchall() - which is what the removed function did.
 > Cal
 > On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant 
 wrote:
 >>
 >> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
 >> > Okay, er.
 >> >
 >> > In reference to the original problem (cursor's not default to
 >> > DictCursor), thus no field names are returned, is there a specific
 >> > reason for this? If not, I'll probably raise a ticket to have it
 >> > considered for change.
 >>
 >> I'm not sure exactly what you are asking, because this is about
 default
 >> behaviour. The choice of a default is usually made according to what
 is
 >> thought to be the most useful, or according to the way it happens to
 >> have been done in the past.
 >>
 >> I also don't know what exactly you are suggesting. Our backwards
 >> compatibility policy means that we aren't going to change the
 default,
 >> unless other people's code is going to work transparently (which
 >> wouldn't be the case here), so it doesn't really matter what the
 >> original reason was, if there was one. If you are suggesting that we
 add
 >> some functionality to make use of DictCursor more useful, then
 certainly
 >> the suggestion is valid.
 >>
 >> Regards,
 >>
 >> Luke
 >>
 >> --
 >> The probability of someone watching you is proportional to the
 >> stupidity of your action.
 >>
 >> 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-developers@googlegroups.com.
 >> To unsubscribe from this group, send email to
 >> django-developers+unsubscr...@googlegroups.com.
 >> For more options, visit this group at
 >> http://groups.google.com/group/django-developers?hl=en.
 >>
 >
 > --
 > You received this message because you are subscribed to the Google
 Groups
 > "Django developers" group.
 > To post to this group, send email to
 django-developers@googlegroups.com.
 > To unsubscribe from this group, send email to
 > django-developers+unsubscr...@googlegroups.com.
 > For more options, visit this group at
 > http://groups.google.com/group/django-developers?hl=en.
 >



 --
 Question the answers

 --
 You received this message because you are subscribed to the Google
 Groups "Django developers" group.
 To post to this group, send email to 

Re: Removal of DictCursor from raw query.. why??

[Cal Leeming [Simplicity Media Ltd]]

@Andy / @ Alex:

Yup, I know how to get this, but the point is, it took me 30 minutes of
searching to find this information out.

What I'm asking, is for consideration of an *EASY* way to get this format,
via something like cursor.fetchall(field_names=True), or
cursor.dictfetchall(), and for that feature to be well documented.



On Thu, Jun 16, 2011 at 4:42 PM, Andy Dustman  wrote:

> You can do something like:
>
> for row in cursor:
>dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
>
> (izip may be better than zip. Your call.)
>
> Or for the whole result set:
>
> result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
> for row in cursor ]
>
> On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
>  wrote:
> > Okay, let me put it another way.
> > Are there any plans to give developers an easy way to retrieve values
> from a
> > cursor.fetchall(), in a DictCursor style?
> > Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
> > What I'm looking for:
> > [{
> >  'f1' : Decimal('0'),
> >  'f2' : Decimal('52'),
> >  'f3' : Decimal('4159'),
> >  'f4' : 9998L
> > }]
> > Maybe something like cursor.fetchall(field_names=True), or
> > cursor.dictfetchall() - which is what the removed function did.
> > Cal
> > On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant 
> wrote:
> >>
> >> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
> >> > Okay, er.
> >> >
> >> > In reference to the original problem (cursor's not default to
> >> > DictCursor), thus no field names are returned, is there a specific
> >> > reason for this? If not, I'll probably raise a ticket to have it
> >> > considered for change.
> >>
> >> I'm not sure exactly what you are asking, because this is about default
> >> behaviour. The choice of a default is usually made according to what is
> >> thought to be the most useful, or according to the way it happens to
> >> have been done in the past.
> >>
> >> I also don't know what exactly you are suggesting. Our backwards
> >> compatibility policy means that we aren't going to change the default,
> >> unless other people's code is going to work transparently (which
> >> wouldn't be the case here), so it doesn't really matter what the
> >> original reason was, if there was one. If you are suggesting that we add
> >> some functionality to make use of DictCursor more useful, then certainly
> >> the suggestion is valid.
> >>
> >> Regards,
> >>
> >> Luke
> >>
> >> --
> >> The probability of someone watching you is proportional to the
> >> stupidity of your action.
> >>
> >> 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-developers@googlegroups.com
> .
> >> To unsubscribe from this group, send email to
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/django-developers?hl=en.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/django-developers?hl=en.
> >
>
>
>
> --
> Question the answers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Removal of DictCursor from raw query.. why??

[Alex Gaynor]

On Thu, Jun 16, 2011 at 10:10 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> In fact let me extend off this a little further.
>
> If I was to provide a code and documentation patch, which allows for an
> easy way to return back values with their field names (via a simple
> field_names=True), would you guys be willing to consider it for the core?
>
> Cal
>
>
> On Thu, Jun 16, 2011 at 6:07 PM, Cal Leeming [Simplicity Media Ltd] <
> cal.leem...@simplicitymedialtd.co.uk> wrote:
>
>> @Andy / @ Alex:
>>
>> Yup, I know how to get this, but the point is, it took me 30 minutes of
>> searching to find this information out.
>>
>> What I'm asking, is for consideration of an *EASY* way to get this format,
>> via something like cursor.fetchall(field_names=True), or
>> cursor.dictfetchall(), and for that feature to be well documented.
>>
>>
>>
>> On Thu, Jun 16, 2011 at 4:42 PM, Andy Dustman wrote:
>>
>>> You can do something like:
>>>
>>> for row in cursor:
>>>dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
>>>
>>> (izip may be better than zip. Your call.)
>>>
>>> Or for the whole result set:
>>>
>>> result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
>>> for row in cursor ]
>>>
>>> On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
>>>  wrote:
>>> > Okay, let me put it another way.
>>> > Are there any plans to give developers an easy way to retrieve values
>>> from a
>>> > cursor.fetchall(), in a DictCursor style?
>>> > Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
>>> > What I'm looking for:
>>> > [{
>>> >  'f1' : Decimal('0'),
>>> >  'f2' : Decimal('52'),
>>> >  'f3' : Decimal('4159'),
>>> >  'f4' : 9998L
>>> > }]
>>> > Maybe something like cursor.fetchall(field_names=True), or
>>> > cursor.dictfetchall() - which is what the removed function did.
>>> > Cal
>>> > On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant 
>>> wrote:
>>> >>
>>> >> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
>>> >> > Okay, er.
>>> >> >
>>> >> > In reference to the original problem (cursor's not default to
>>> >> > DictCursor), thus no field names are returned, is there a specific
>>> >> > reason for this? If not, I'll probably raise a ticket to have it
>>> >> > considered for change.
>>> >>
>>> >> I'm not sure exactly what you are asking, because this is about
>>> default
>>> >> behaviour. The choice of a default is usually made according to what
>>> is
>>> >> thought to be the most useful, or according to the way it happens to
>>> >> have been done in the past.
>>> >>
>>> >> I also don't know what exactly you are suggesting. Our backwards
>>> >> compatibility policy means that we aren't going to change the default,
>>> >> unless other people's code is going to work transparently (which
>>> >> wouldn't be the case here), so it doesn't really matter what the
>>> >> original reason was, if there was one. If you are suggesting that we
>>> add
>>> >> some functionality to make use of DictCursor more useful, then
>>> certainly
>>> >> the suggestion is valid.
>>> >>
>>> >> Regards,
>>> >>
>>> >> Luke
>>> >>
>>> >> --
>>> >> The probability of someone watching you is proportional to the
>>> >> stupidity of your action.
>>> >>
>>> >> 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-developers@googlegroups.com.
>>> >> To unsubscribe from this group, send email to
>>> >> django-developers+unsubscr...@googlegroups.com.
>>> >> For more options, visit this group at
>>> >> http://groups.google.com/group/django-developers?hl=en.
>>> >>
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "Django developers" group.
>>> > To post to this group, send email to
>>> django-developers@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> > django-developers+unsubscr...@googlegroups.com.
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/django-developers?hl=en.
>>> >
>>>
>>>
>>>
>>> --
>>> Question the answers
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To post to this group, send email to django-developers@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-developers+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> 

Re: Removal of DictCursor from raw query.. why??

[Cal Leeming [Simplicity Media Ltd]]

In fact let me extend off this a little further.

If I was to provide a code and documentation patch, which allows for an easy
way to return back values with their field names (via a simple
field_names=True), would you guys be willing to consider it for the core?

Cal

On Thu, Jun 16, 2011 at 6:07 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> @Andy / @ Alex:
>
> Yup, I know how to get this, but the point is, it took me 30 minutes of
> searching to find this information out.
>
> What I'm asking, is for consideration of an *EASY* way to get this format,
> via something like cursor.fetchall(field_names=True), or
> cursor.dictfetchall(), and for that feature to be well documented.
>
>
>
> On Thu, Jun 16, 2011 at 4:42 PM, Andy Dustman  wrote:
>
>> You can do something like:
>>
>> for row in cursor:
>>dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
>>
>> (izip may be better than zip. Your call.)
>>
>> Or for the whole result set:
>>
>> result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
>> for row in cursor ]
>>
>> On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
>>  wrote:
>> > Okay, let me put it another way.
>> > Are there any plans to give developers an easy way to retrieve values
>> from a
>> > cursor.fetchall(), in a DictCursor style?
>> > Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
>> > What I'm looking for:
>> > [{
>> >  'f1' : Decimal('0'),
>> >  'f2' : Decimal('52'),
>> >  'f3' : Decimal('4159'),
>> >  'f4' : 9998L
>> > }]
>> > Maybe something like cursor.fetchall(field_names=True), or
>> > cursor.dictfetchall() - which is what the removed function did.
>> > Cal
>> > On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant 
>> wrote:
>> >>
>> >> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
>> >> > Okay, er.
>> >> >
>> >> > In reference to the original problem (cursor's not default to
>> >> > DictCursor), thus no field names are returned, is there a specific
>> >> > reason for this? If not, I'll probably raise a ticket to have it
>> >> > considered for change.
>> >>
>> >> I'm not sure exactly what you are asking, because this is about default
>> >> behaviour. The choice of a default is usually made according to what is
>> >> thought to be the most useful, or according to the way it happens to
>> >> have been done in the past.
>> >>
>> >> I also don't know what exactly you are suggesting. Our backwards
>> >> compatibility policy means that we aren't going to change the default,
>> >> unless other people's code is going to work transparently (which
>> >> wouldn't be the case here), so it doesn't really matter what the
>> >> original reason was, if there was one. If you are suggesting that we
>> add
>> >> some functionality to make use of DictCursor more useful, then
>> certainly
>> >> the suggestion is valid.
>> >>
>> >> Regards,
>> >>
>> >> Luke
>> >>
>> >> --
>> >> The probability of someone watching you is proportional to the
>> >> stupidity of your action.
>> >>
>> >> 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-developers@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> django-developers+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/django-developers?hl=en.
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Django developers" group.
>> > To post to this group, send email to django-developers@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> > django-developers+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> >
>>
>>
>>
>> --
>> Question the answers
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

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

Re: Removal of DictCursor from raw query.. why??

[Andy Dustman]

You can do something like:

for row in cursor:
dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )

(izip may be better than zip. Your call.)

Or for the whole result set:

result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
for row in cursor ]

On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Okay, let me put it another way.
> Are there any plans to give developers an easy way to retrieve values from a
> cursor.fetchall(), in a DictCursor style?
> Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
> What I'm looking for:
> [{
>  'f1' : Decimal('0'),
>  'f2' : Decimal('52'),
>  'f3' : Decimal('4159'),
>  'f4' : 9998L
> }]
> Maybe something like cursor.fetchall(field_names=True), or
> cursor.dictfetchall() - which is what the removed function did.
> Cal
> On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant  wrote:
>>
>> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
>> > Okay, er.
>> >
>> > In reference to the original problem (cursor's not default to
>> > DictCursor), thus no field names are returned, is there a specific
>> > reason for this? If not, I'll probably raise a ticket to have it
>> > considered for change.
>>
>> I'm not sure exactly what you are asking, because this is about default
>> behaviour. The choice of a default is usually made according to what is
>> thought to be the most useful, or according to the way it happens to
>> have been done in the past.
>>
>> I also don't know what exactly you are suggesting. Our backwards
>> compatibility policy means that we aren't going to change the default,
>> unless other people's code is going to work transparently (which
>> wouldn't be the case here), so it doesn't really matter what the
>> original reason was, if there was one. If you are suggesting that we add
>> some functionality to make use of DictCursor more useful, then certainly
>> the suggestion is valid.
>>
>> Regards,
>>
>> Luke
>>
>> --
>> The probability of someone watching you is proportional to the
>> stupidity of your action.
>>
>> 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-developers@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 
Question the answers

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

Re: Better error message for django.core.urlresolvers.reverse

[tomv]

Hi Gregor,

Cool, will do this after my holiday.

Tom

On Jun 12, 12:01 pm, Gregor Müllegger  wrote:
> Hi Tom,
>
> currently it seems that the url resolver that is actually raising the
> error doesn't know about in which namespace he acts. However I think
> as well that this might be a usefull addition to the error message.
>
> I would suggest adding a ticket to django's bugtracker [1] for this.
> Ideally write a patch for this issue and attach it to the ticket.
>
> [1]https://code.djangoproject.com/
>
> --
> Servus,
> Gregor Müllegger
>
> 2011/6/9 tomv :
>
>
>
>
>
>
>
> > Hi,
>
> > This is the current error message when a url name or argument doesn't
> > exist:
>
>  reverse('core:non_existant')
> > NoReverseMatch: Reverse for 'non_existant' with arguments '()' and
> > keyword arguments '{}' not found.
>
> > Is there support for adding the namespace into the error message?
>
> > Tom
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-developers@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Removal of DictCursor from raw query.. why??

[Cal Leeming [Simplicity Media Ltd]]

Okay, let me put it another way.

Are there any plans to give developers an easy way to retrieve values from a
cursor.fetchall(), in a DictCursor style?

Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)

What I'm looking for:
[{
 'f1' : Decimal('0'),
 'f2' : Decimal('52'),
 'f3' : Decimal('4159'),
 'f4' : 9998L
}]

Maybe something like cursor.fetchall(field_names=True), or
cursor.dictfetchall() - which is what the removed function did.

Cal

On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant  wrote:

> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
> > Okay, er.
> >
> > In reference to the original problem (cursor's not default to
> > DictCursor), thus no field names are returned, is there a specific
> > reason for this? If not, I'll probably raise a ticket to have it
> > considered for change.
>
> I'm not sure exactly what you are asking, because this is about default
> behaviour. The choice of a default is usually made according to what is
> thought to be the most useful, or according to the way it happens to
> have been done in the past.
>
> I also don't know what exactly you are suggesting. Our backwards
> compatibility policy means that we aren't going to change the default,
> unless other people's code is going to work transparently (which
> wouldn't be the case here), so it doesn't really matter what the
> original reason was, if there was one. If you are suggesting that we add
> some functionality to make use of DictCursor more useful, then certainly
> the suggestion is valid.
>
> Regards,
>
> Luke
>
> --
> The probability of someone watching you is proportional to the
> stupidity of your action.
>
> 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-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Logging configuration and handle_uncaught_exception

[Carl Meyer]

On 06/16/2011 08:47 AM, Russell Keith-Magee wrote:
> The behavior that is implemented in the 500 handler is a bit
> convoluted, but it was designed to be a drop-in replacement for the
> behavior that existed in 1.2 -- i.e., server error emails were not
> sent in DEBUG mode. I remember looking at this exact problem; as I
> recall, I was faced with the option of filtering in the handler (which
> would mean providing a email handler that wouldn't send emails under
> certain circumstances) or filtering at the logging call level. In the
> interest of making the admin email handler general purpose, I opted
> for the second option.
> 
> Now, I'm not absolutely bound to this specific implementation, only to
> the preservation of existing behavior without hobbling the email
> handler as a general purpose tool.

This is a case for a custom Filter object [1]. The filter object
implementation would only be a few lines, to reject logging when DEBUG
is True, and can be attached to the admin email handler in the default
logging configuration. [2] This way the logging call can occur in all
code paths, and the admin email handler itself can remain
general-purpose, but the backwards-compatible behavior can be maintained.

Matt, if you'd be willing to open a ticket for this, that'd be helpful.
If you feel like putting together a patch using the Filter approach,
that'd be even better ;-)

Carl

[1] http://docs.python.org/library/logging.html#filter-objects
[2]
http://docs.python.org/library/logging.config.html#dictionary-schema-details

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

Re: Removal of DictCursor from raw query.. why??

[Luke Plant]

On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
> Okay, er.
> 
> In reference to the original problem (cursor's not default to
> DictCursor), thus no field names are returned, is there a specific
> reason for this? If not, I'll probably raise a ticket to have it
> considered for change.

I'm not sure exactly what you are asking, because this is about default
behaviour. The choice of a default is usually made according to what is
thought to be the most useful, or according to the way it happens to
have been done in the past.

I also don't know what exactly you are suggesting. Our backwards
compatibility policy means that we aren't going to change the default,
unless other people's code is going to work transparently (which
wouldn't be the case here), so it doesn't really matter what the
original reason was, if there was one. If you are suggesting that we add
some functionality to make use of DictCursor more useful, then certainly
the suggestion is valid.

Regards,

Luke

-- 
The probability of someone watching you is proportional to the
stupidity of your action.

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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Logging configuration and handle_uncaught_exception

[Russell Keith-Magee]

On Tue, Jun 14, 2011 at 7:33 PM, Matt Bennett  wrote:
> On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip  wrote:
>> On Jun 10, 2:05 pm, Matt Bennett  wrote:
>>
>>> Is there a reason the call to logger.error can't come before we return
>>> the technical_500_response when DEBUG=True? It seems to me that the
>>> debug level should be checked in each individual handler, rather than
>>> determining whether the error is passed to the logger at all.
>>
>> Aren't these two separate things? It makes sense to have the logging
>> of errors occur in all code paths, but that isn't connected with
>> levels on handlers. The first requires the logging call to be added to
>> the code, whereas levels on handlers can be configured to be as
>> verbose (or not) as you like, independently of logging calls in the
>> code.
>>
>
> I think we're saying the same thing - my point is that the logging of
> errors should occur in call code paths. Currently, an unhandled view
> error is *not* logged if settings.DEBUG is True. To be clear, this has
> nothing to do with the log levels on the handlers.

For the benefit of the archive: there is some method to the madness here :-)

The behavior that is implemented in the 500 handler is a bit
convoluted, but it was designed to be a drop-in replacement for the
behavior that existed in 1.2 -- i.e., server error emails were not
sent in DEBUG mode. I remember looking at this exact problem; as I
recall, I was faced with the option of filtering in the handler (which
would mean providing a email handler that wouldn't send emails under
certain circumstances) or filtering at the logging call level. In the
interest of making the admin email handler general purpose, I opted
for the second option.

Now, I'm not absolutely bound to this specific implementation, only to
the preservation of existing behavior without hobbling the email
handler as a general purpose tool.

Yours,
Russ Magee %-)

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

Re: Removal of DictCursor from raw query.. why??

[Luke Plant]

On 16/06/11 13:34, Cal Leeming [Simplicity Media Ltd] wrote:
> Hi all,
...
> Could someone indicate if there is a reason for this, or if I should be
> filing a bug report?

As the changeset comment indicates, the snippet you wanted was removed
because it was an internal function that was no longer being used in
Django. Our backwards compatibility promise does not extend to
undocumented internals, so there isn't a bug here.

Regards,

Luke

-- 
The probability of someone watching you is proportional to the
stupidity of your action.

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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: FYI: added a proper "easy" field to Trac

[Luke Plant]

On 16/06/11 08:34, Alex Kamedov wrote:
> On Thu, Jun 16, 2011 at 7:14 AM, Julien Phalip  > wrote:
> 
> By the way, anybody with a Trac account should have edit access to the
> wiki, so feel free to make the change directly next time you find an
> inconsistency ;)
> 
> Yes, may be you are right.
> I have Trac account, but "Edit this page" button isn't shown for me on
> Wiki Start page.

Yes, a few key pages are locked, I think in an attempt to deter spammers.

Luke

-- 
The probability of someone watching you is proportional to the
stupidity of your action.

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-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: ImportError catching in urlresolvers.py

[Russell Keith-Magee]

On Thu, Jun 16, 2011 at 3:09 PM, Bas Peschier  wrote:
> For reference, I added a patch to https://code.djangoproject.com/ticket/10802
> which takes Russell's approach.

Looks good to me! I've just marked to RFC. Thanks for the patch Bas!

Yours,
Russ Magee %-)

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

Re: Customizable serialization. (Finally?)

[Tom Christie]

Yup.
The current implementation (see the github repo) allows properties and 
methods that only take a 'self' argument to be serialized by adding the name 
to 'fields' or 'include'.
If you need anything more involved then you'd write a custom method on the 
Serializer class. (or a custom SerializerField if the final API uses that 
style instead.)

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

Re: Customizable serialization. (Finally?)

[mofle]

Looks really good, the current implementation for serialization is
pretty limited, so this will be a breath of fresh air :)

Using the proposed Serializations class, will it be possible to
serialize properties of a model that is not fields, for example
methods?




On Jun 15, 12:18 pm, Tom Christie  wrote:
> > A suggestion though, is to be able to declare serializers in a
> > similar fashion as models or forms.
>
> Actually that's a fair point, yup - the proposal could be made a little
> closer to the existing Forms and Models APIs.
> Something along these lines...
>
> class ModelPKField(SerializerField):
>     def get_value(self, obj, key):
>         return unicode(obj.pk)
>
> class ModelNameField(SerializerField):
>     def get_value(self, obj, key):
>         return unicode(obj._meta)
>
> class ModelFieldSetField(SerializerField):
>     def get_value(self, obj, key):
>         return FieldsSerializer().serialize(obj)
>
> class RelatedPKField(SerializerField):
>     def get_value(self, obj, key):
>         return unicode(getattr(obj, key).pk)
>
> class FieldsSerializer(Serializer):
>     """
>     Serializes only the fields on a model.
>     """
>     class Meta:
>         exclude = ('id', 'pk')
>         default_related_field = RelatedPKField()
>
> class DjangoSerializer(Serializer):
>     """
>     Serializes into the existing django style.
>     """
>     pk = ModelPKField()
>     model = ModelNameField()
>     fields = ModelFieldSetField()

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

Re: FYI: added a proper "easy" field to Trac

[Alex Kamedov]

On Thu, Jun 16, 2011 at 7:14 AM, Julien Phalip  wrote:
>
> By the way, anybody with a Trac account should have edit access to the
> wiki, so feel free to make the change directly next time you find an
> inconsistency ;)

Yes, may be you are right.
I have Trac account, but "Edit this page" button isn't shown for me on Wiki
Start page.


-- 
Alex Kamedov
skype: kamedovwww: kamedov.ru

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

Re: ImportError catching in urlresolvers.py

[Bas Peschier]

For reference, I added a patch to https://code.djangoproject.com/ticket/10802
which takes Russell's approach.

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

Re: ImportError catching in urlresolvers.py

[Thomas Guettler]

On 14.06.2011 22:19, Michael Blume wrote:
> In RegexURLPattern._get_callback, we attempt to fetch the callable named
> by the URL pattern, and catch a possible ImportError if this fails. If
> so, we raise ViewDoesNotExist.
> 
> try:
> self._callback = get_callable(self._callback_str)
> except ImportError, e:
> mod_name, _ = get_mod_func(self._callback_str)
> raise ViewDoesNotExist("Could not import %s. Error was: %s"
> % (mod_name, str(e)))

I uncomment the try...except part in my local django version (and the 
AttributeError). I want to see the original
exception. It would be nice to have a better solution in django. Maybe a 
settings variable CATCH_EXCEPTIONS?

  Thomas

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

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