Re: ImportError catching in urlresolvers.py

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 unsubs

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

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 is

Re: Customizable serialization. (Finally?)

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

Re: Customizable serialization. (Finally?)

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 SerializerF

Re: ImportError catching in urlresolvers.py

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

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

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

Removal of DictCursor from raw query.. why??

Hi all, I've had a look through the tickets but can't find anything in relation to why DictCursor is not the default for all cursor() created manually. I can see the snippet needed was removed here: https://code.djangoproject.com/changeset/5970 Examples of how to use the dictfetchall() are here:

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

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

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

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. Cal On Thu, Jun 16, 2011 at 2:08 PM, Luke Plant wrote: > On 16/06/1

Re: Logging configuration and handle_uncaught_exception

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

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

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

Re: Logging configuration and handle_uncaught_exception

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

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

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

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

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 addi

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

On Thu, Jun 16, 2011 at 7:03 AM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> 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(

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

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,

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

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

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

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

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

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

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

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

required=True for BooleanFields

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 Field

Re: Template Engine Compilation and Runtime Refactoring Progress

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 subscrib

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

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

Re: required=True for BooleanFields

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

Re: required=True for BooleanFields

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 nega

Re: required=True for BooleanFields

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