Re: Site down

[Russell Keith-Magee]

On Sat, Jun 18, 2011 at 12:26 PM, Ori  wrote:
> Hi guys,
>
> Apologies if this isn't the right venue for raising the alarm, but it
> seems djangoprojects.com is down.

Hi Ori,

Thanks for the alert -- I'm trying to find someone with the keys to
give the server a kick in a sensitive spot.

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.

Site down

[Ori]

Hi guys,

Apologies if this isn't the right venue for raising the alarm, but it
seems djangoprojects.com is down.

Cheers,
Ori

-- 
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: 5-for-1?

[Stephen Burrows]

Thanks, Carl. :-)

I probably should've written a thank you note sooner & separately. As
it is, I am also writing to request a five-for-one again.
I have reviewed:
16168
16173
16176
16235
16237

I would love it if someone could look at 13956 [1]

Best,
Stephen

[1] http://code.djangoproject.com/ticket/13956

On Jun 7, 12:24 pm, Carl Meyer  wrote:
> Hi Stephen,
>
> On 06/07/2011 02:37 AM, Stephen Burrows wrote:
>
> > Hi - is the 5-for-1 deal still active on ticket reviews? [1]
> > If so, I've reviewed the following tickets:
>
> > 3624
> > 16152
> > 16157
> > 16158
> > 16166
>
> > And would love it if someone could have a look at ticket 14082 [2].
>
> > If not, ah well. :-)
>
> Thanks for the ticket reviews, and your work on the patch. Committed in
> r16334 [1]
>
> Carl
>
>   [1]https://code.djangoproject.com/changeset/16334

-- 
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: Declarable FormSet and friends

[Iván Raskovsky]

On Fri, Jun 17, 2011 at 4:15 PM, Bas Peschier  wrote:
> Hello everyone,
>
> after discussion on IRC with rasca I opened up a ticket [1] about
> making FormSets declarable.
>
> We have been down this route with ModelForm and it seems to make sense
> to be able to declare your FormSet somewhere instead of having to
> generate it.
>
> The idea given is you can do:
>
>  class MyFormSet(formsets.FormSet):
>    can_delete = True
>    form = MyForm
>    extra = 3
>
> This is almost possible already (BaseFormSet actually can be
> subclassed if you add all the arguments to your definition), but it
> might be interesting to think about the consequences. rasca is working
> on extending CBV [2] which can use this.
>
> In the mean time we looked at "removing" the factories, but for now
> the admin makes good use of completely flexible generation of
> ModelForm and ModelFormSets.
>
> Ideas?
>
> /Bas
>
>
> [1]: https://code.djangoproject.com/ticket/16289
> [2]: https://code.djangoproject.com/ticket/16256

Okey, so this have been raised before in #10403 [0]. It's marked DDN
by jacob, but now we have some concrete usages where we might benefit
from the declarable FormSets and friends.

Actually, for the new CBV what would came in handy is having the
defaults set as attributes of the class; and in the factories, only
override those attributes whose value isn't None with type(). This
way, for example in the inlines generic cbv, the user can set some
attrs such as can_delete, fields and exclude for each InlineFormSet
and the view can handle the parent_class, without overriding with None
the user set attrs.

It's completely backwards compatible and the code for these cbv would
end up beeing much cleaner.

Regards,
Iván

[0] https://code.djangoproject.com/ticket/10403

-- 
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

[Matt Bennett]

On Fri, Jun 17, 2011 at 6:45 PM, Vinay Sajip  wrote:
> Matt Bennett  writes:
>
>>
>> > 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
>>
>> Here you are: https://code.djangoproject.com/ticket/16288
>>
>> Since logging Filters are not specific to an individual logger or
>> handler, I've just called it DebugFalseFilter. It's not a pretty name,
>> but I couldn't come up with anything better - I decided it should
>> convey what the filter allows through, but AFAIK there's no name for
>> "not debug mode".
>
> Reposting this, after Google swallowed my earlier response. Sorry if it
> eventually turns up, making this a double post ...
>
> A more general solution would be something like this:
>
> class ConditionFilter(logging.Filter):
>    def __init__(self, condition):
>        self.condition = condition
>
>    def filter(self, record):
>        return self.condition
>
> which you can then use in the logging configuration using something like
>
> 'require_debug_false': {
>    '()': 'django.utils.log.ConditionFilter',
>    'condition': not DEBUG,
> }
>
> This will allow the filter to be used in more places, e.g. you could use a 
> more
> complex settings-time condition.
>
> Regards,
>
> Vinay Sajip
>

+1. Perhaps the reason I don't like DebugFalseFilter as a name is that
it's so specific.

-- 
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.

Declarable FormSet and friends

[Bas Peschier]

Hello everyone,

after discussion on IRC with rasca I opened up a ticket [1] about
making FormSets declarable.

We have been down this route with ModelForm and it seems to make sense
to be able to declare your FormSet somewhere instead of having to
generate it.

The idea given is you can do:

  class MyFormSet(formsets.FormSet):
can_delete = True
form = MyForm
extra = 3

This is almost possible already (BaseFormSet actually can be
subclassed if you add all the arguments to your definition), but it
might be interesting to think about the consequences. rasca is working
on extending CBV [2] which can use this.

In the mean time we looked at "removing" the factories, but for now
the admin makes good use of completely flexible generation of
ModelForm and ModelFormSets.

Ideas?

/Bas


[1]: https://code.djangoproject.com/ticket/16289
[2]: https://code.djangoproject.com/ticket/16256

-- 
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.

Javascript Testing

[Sean Bleier]

Hello everyone,

A couple months ago I started work on a django branch [1] (with the help of
@jezdez) that introduces a framework for writing javascript unit tests using
QUnit[2].  I started with QUnit because Django already included jQuery in
the admin and seemed like a natural extension, but it would be nice to hear
opinions from people that know more about javascript testing than I.

Since I haven't touch it in a couple months, I thought I would share it with
django-developers to get some more eyes on it and discuss any missing
features or implementation details. It also be nice if Idan or any other
designery person could look it over and give some UI/UX advice.

Just to give a overview, the javascript testing framework is initiated by
first collecting static media and then starting a special runserver:

./manage.py collectstatic
./manage.py jstest

This starts a runserver that collects and serves everything you need to run
the javascript tests found within an installed app. More detail can be found
in these preliminary docs[3], though they need to be moved into their proper
place within the docs directory.

I'm hoping we can figure out a way forward so that we can start writing
tests for the admin and elsewhere.

Cheers,

--Sean


[1] https://github.com/sebleier/django/tree/qunit
[2] http://docs.jquery.com/Qunit
[3]
https://github.com/sebleier/django/blob/qunit/django/test/javascript/__init__.py

-- 
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??

[akaariai]

On Jun 17, 8:02 pm, Ian Kelly  wrote:
 > The thing is, this is a DB API snippet, not a Django snippet
> specifically.  If Django were a DB API toolbox, then it might make
> sense to include it in some form or other.  But it's not, so in the
> interest of keeping things relatively tidy I'm a -0 on this.

It is often said here that Django ORM is designed to do 80% of the
stuff, the rest can be done using raw SQL. So, giving pointers to
users how to perform the raw SQL as painlessly as possible is
something Django documentation should do.

- Anssi

-- 
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

[Vinay Sajip]

Matt Bennett  writes:

> 
> > 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 
> 
> Here you are: https://code.djangoproject.com/ticket/16288
> 
> Since logging Filters are not specific to an individual logger or
> handler, I've just called it DebugFalseFilter. It's not a pretty name,
> but I couldn't come up with anything better - I decided it should
> convey what the filter allows through, but AFAIK there's no name for
> "not debug mode".

Reposting this, after Google swallowed my earlier response. Sorry if it
eventually turns up, making this a double post ...

A more general solution would be something like this:

class ConditionFilter(logging.Filter):
def __init__(self, condition):
self.condition = condition

def filter(self, record):
return self.condition

which you can then use in the logging configuration using something like

'require_debug_false': {
'()': 'django.utils.log.ConditionFilter',
'condition': not DEBUG,
}

This will allow the filter to be used in more places, e.g. you could use a more
complex settings-time condition.

Regards,

Vinay Sajip

-- 
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]

Hi Julien,

On 06/17/2011 12:08 PM, Julien Phalip wrote:
> Just noting that another "filtering" functionality has recently been
> added to trunk [1]. It is a different kind of filtering than what's
> being discussed here -- it is to filter out sensitive information from
> error reports when they're being produced. Maybe the naming of one of
> those functionalities might need to be reconsidered in order to avoid
> confusion in the docs and APIs. I'm not sure. Just thought I'd point
> it out ;)

Since "filters" are already a built-in feature of the logging package in
Python's standard library, and we're just making use of that existing
feature, we don't have the option of changing naming here: i.e., the
keys in LOGGING must be named "filters" or they just won't work with
logging.dictConfig. (Even if we could do it, it'd be a mistake to try to
impose alternate Django terminology on a feature of a Python standard
library component).

In any case, we already have plenty of uses of "filter" in Django:
there's the ORM .filter() method, and ModelAdmin.list_filter, just off
the top of my head. I don't think there's a problem here: "filter" is a
generic term, and if there's any potential for confusion it must be
qualified. "Error filtering" vs "logging filters" vs "admin changelist
filters", etc.

> (By the way, "production" is a common generic term used for when DEBUG
> is False)

True that it's used for that, but it doesn't exclusively mean that;
therefore I think DebugFalseFilter is a clearer name than
ProductionFilter. I would have to look at docs or implementation to be
confident I knew what the latter did; not so for the former.

Carl

-- 
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

[Julien Phalip]

On Jun 17, 10:48 pm, Matt Bennett  wrote:
> > 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 ;-)
>
> Here you are:https://code.djangoproject.com/ticket/16288
>
> Since logging Filters are not specific to an individual logger or
> handler, I've just called it DebugFalseFilter. It's not a pretty name,
> but I couldn't come up with anything better - I decided it should
> convey what the filter allows through, but AFAIK there's no name for
> "not debug mode".
>
> Matt.

Hi,

Just noting that another "filtering" functionality has recently been
added to trunk [1]. It is a different kind of filtering than what's
being discussed here -- it is to filter out sensitive information from
error reports when they're being produced. Maybe the naming of one of
those functionalities might need to be reconsidered in order to avoid
confusion in the docs and APIs. I'm not sure. Just thought I'd point
it out ;)

(By the way, "production" is a common generic term used for when DEBUG
is False)

Julien

[1] 
https://docs.djangoproject.com/en/dev/howto/error-reporting/#filtering-error-reports

-- 
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??

[Ian Kelly]

On Fri, Jun 17, 2011 at 5:54 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Because I feel this is just something that should work (or be available) out
> of the box. There are plenty of other places where Django docs has included
> code snippets to give the user a heads up, and I think this is the perfect
> case for one.
>
> If anyone has any objections to this, please let me know, if not ill put in
> a ticket for consideration.

The thing is, this is a DB API snippet, not a Django snippet
specifically.  If Django were a DB API toolbox, then it might make
sense to include it in some form or other.  But it's not, so in the
interest of keeping things relatively tidy I'm a -0 on this.

Cheers,
Ian

-- 
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??

[akaariai]

On Jun 17, 2:54 pm, "Cal Leeming [Simplicity Media Ltd]"
 wrote:
> Because I feel this is just something that should work (or be available) out
> of the box. There are plenty of other places where Django docs has included
> code snippets to give the user a heads up, and I think this is the perfect
> case for one.
>
> If anyone has any objections to this, please let me know, if not ill put in
> a ticket for consideration.

I just wanted to say I support having something documented about this.
Without documentation new users will most likely use index based
cursors. I know I used to do that.

The problem with no documentation is not so much that it would be hard
to find a snippet about dict cursor implementation. It is more that
new users don't know that using index based cursors might not be the
best of ideas.

 - Anssi

-- 
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]

Hi Matt,

On 06/17/2011 07:48 AM, Matt Bennett wrote:
> Since logging Filters are not specific to an individual logger or
> handler, I've just called it DebugFalseFilter. It's not a pretty name,
> but I couldn't come up with anything better - I decided it should
> convey what the filter allows through, but AFAIK there's no name for
> "not debug mode".

The name is fine - thanks for the patch! I realized there's still a bit
of a back-compat issue, I've commented on the ticket with a possible
solution. I'd like to get Russ' take on it, if he's ok with the plan I
can take it from here.

Carl

-- 
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: Template Engine Compilation and Runtime Refactoring Progress

[Alex Gaynor]

On Fri, Jun 17, 2011 at 5:18 AM, Anatoly Vostryakov
wrote:

> Hi, Armin!
>
>  I've thought today. May be it will possible to add support of
> parameters for functions or object methods in django templates.
> I mean, something like this in django template:
>
> {{  obj.method(parameter1, parameter2) }}
>
>  How I remember it is possible in jinja2 someway and it is what I
> missing in django templates. I wrote it to you because you're working
> with django templates now and author of jinja2.
>
> Regards,
> Anatoly Vostryakov
>
> On Jun 17, 4:07 am, Armin Ronacher 
> wrote:
> > 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.
>
>
No, the purpose of this GSOC is not to change the semantics of the template
engine.

Alex

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

-- 
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: Template Engine Compilation and Runtime Refactoring Progress

[Anatoly Vostryakov]

Hi, Armin!

  I've thought today. May be it will possible to add support of
parameters for functions or object methods in django templates.
I mean, something like this in django template:

{{  obj.method(parameter1, parameter2) }}

  How I remember it is possible in jinja2 someway and it is what I
missing in django templates. I wrote it to you because you're working
with django templates now and author of jinja2.

Regards,
Anatoly Vostryakov

On Jun 17, 4:07 am, Armin Ronacher 
wrote:
> 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.

Re: Logging configuration and handle_uncaught_exception

[Matt Bennett]

> 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 ;-)

Here you are: https://code.djangoproject.com/ticket/16288

Since logging Filters are not specific to an individual logger or
handler, I've just called it DebugFalseFilter. It's not a pretty name,
but I couldn't come up with anything better - I decided it should
convey what the filter allows through, but AFAIK there's no name for
"not debug mode".

Matt.

-- 
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]]

Because I feel this is just something that should work (or be available) out
of the box. There are plenty of other places where Django docs has included
code snippets to give the user a heads up, and I think this is the perfect
case for one.

If anyone has any objections to this, please let me know, if not ill put in
a ticket for consideration.
On 17 Jun 2011 04:55, "burc...@gmail.com"  wrote:
> 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
>> >> 

Re: required=True for BooleanFields

[Luke Plant]

On 17/06/11 07:00, Tai Lee wrote:

> If this behaviour were to change, `required` would become a completely
> meaningless argument to BooleanField because no value in the GET or
> POST data is normalised to `False` because of the way checkbox values
> are submitted in HTML forms.

The suggestion is not to change the behaviour of the 'required'
attribute, which has to work the way it does, for reasons you describe.
The suggestion is to change the default - so that this field, in
contrast to most (every?) other field, has 'required=False' by default.

Alternatively, you could define 'required' to be meaningless for check
boxes, and therefore ignored, since you cannot *not* return a value in
some way, and add another attribute like 'require_true' to get the
current behaviour. However, that would only be sensible if BooleanField
knows that it is using a check box widget, and other widgets are
possible that don't have this limitation e.g. two radio buttons with
neither initially selected.

So it is difficult to work out what behaviour is correct and consistent
here - the most obvious definition of 'required' (to me, anything) is
essentially meaningless for check boxes, the most common case, but not
for other widgets, yet it is an attribute of the field which is widget
agnostic.

Luke

-- 
LORENZ'S LAW OF MECHANICAL REPAIR:
After your hands become coated with grease, your nose will begin to
itch.

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: required=True for BooleanFields

[Tai Lee]

On Jun 17, 3:41 pm, David Cramer  wrote:
> 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.

You can do that easily right now without changing Django by adding
`required=False` the BooleanField on your form. This is less
repetitive than writing the same validation method over and over
again.

def validate_somebooleanfield(self):
value = self.cleaned_data.get('somebooleanfield')
if not value:
raise forms.ValidationError('This field is required.')
return value

If this behaviour were to change, `required` would become a completely
meaningless argument to BooleanField because no value in the GET or
POST data is normalised to `False` because of the way checkbox values
are submitted in HTML forms.

The nature of boolean fields means that it's impossible to NOT provide
a value. NullBooleanField is used in those cases.

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-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.