Re: Intermittent IOError exception raised and emailed to admins during file upload.

Thanks for your detailed explanation, Graham. I'll try to approach this from another angle and see if I can determine what is actually causing the connections to be dropped, as I'm seeing this error a few times a day on a low traffic site using Apache at the front for static media, with proxy pass

Re: Feature request: Abstract ManyToManyField

Can you give an example of the model(s) you're talking about? -- Gert Mobile: +32 498725202 Twitter: @gvangool Web: http://gert.selentic.net On Thu, Feb 3, 2011 at 22:36, Mike Lindsey wrote: > I'm doing something with bidirectional ManyToManyFields, in a project >

Re: Intermittent IOError exception raised and emailed to admins during file upload.

The problem is you can't just catch IOError, because the presence of WSGI middleware may mean that IOError could be generated for other reasons when reading wsgi.input. To base detection on the description in the IOError, ie., 'request data read error', would mean having to know what that

Intermittent IOError exception raised and emailed to admins during file upload.

There are many questions about this on django-users. The usual answer is to ignore the errors, which are probably generated as a result of the client prematurely terminating a connection, usually during an upload. Nobody seems to be able to reliably reproduce the error, and it seems to happen

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Thu, Feb 3, 2011 at 4:55 PM, Richard Laager wrote: > On Thu, 2011-02-03 at 13:46 -0500, Tobias McNulty wrote: > > the behavior of all fields, except for BooleanField, is to default to > > the empty value supported by that field. > ... > > On the other hand, False is in no

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Thu, 2011-02-03 at 13:46 -0500, Tobias McNulty wrote: > the behavior of all fields, except for BooleanField, is to default to > the empty value supported by that field. ... > On the other hand, False is in no way an "empty value." From the point of view of the model layer, your point makes

Feature request: Abstract ManyToManyField

I'm doing something with bidirectional ManyToManyFields, in a project I'm working on, that is resulting in duplicate attempts to create the intermediate tables. I'm perfectly open to suggestions of "You're doing it wrong" if they come with advice on how to fix my problem, without losing the easy

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Thu, Feb 3, 2011 at 1:22 PM, anb wrote: > On Feb 2, 3:08 pm, Chris Beaven wrote: > > On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote: > > > > > Rather, a BooleanField that raises an error on an attempt to save an > > >

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Wed, Feb 2, 2011 at 6:08 PM, Chris Beaven wrote: > On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote: >> >> Rather, a BooleanField that raises an error on an attempt to save an >> instance that has no value set is what's being asked for. The quiet

Re: Error: cannot import name SpooledTemporaryFile

This list is for discussing the development of Django itself. Please post this type of question to django-users. That error is from the application you are trying to run and has nothing to do with Django itself. cheers On Thu, Feb 3, 2011 at 12:35 PM, b...@live.se wrote: > Hi all

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

On Feb 2, 3:08 pm, Chris Beaven wrote: > On Friday, January 21, 2011 12:35:58 PM UTC+13, Karen Tracey wrote: > > > Rather, a BooleanField that raises an error on an attempt to save an > > instance that has no value set is what's being asked for. The quiet always > >

Error: cannot import name SpooledTemporaryFile

Hi all , I install dionaea on my Debian 5.0 (VM) when i run carniwwwhore : debian:/opt/carniwwwhore# python manage.py runserver Error: cannot import name SpooledTemporaryFile debian:/opt/carniwwwhore# python --version Python 2.5.2 any idea ? thanks -- You received this message because you are

Re: ForbiddenMixin for Django?

On 3 February 2011 18:06, Jari Pennanen wrote: > If everyone is happy with class decorators we should do it. But bear > in mind that removing the ability to override them practicly means > that only Final class should define them. Which I think is actually a good thing

Re: ForbiddenMixin for Django?

If everyone is happy with class decorators we should do it. But bear in mind that removing the ability to override them practicly means that only Final class should define them. That could lead to following annoying situations: Base classes could e.g. enforce using some requirement for

Re: ForbiddenMixin for Django?

On 3 February 2011 16:09, Jari Pennanen wrote: > > But I would be happy for class decorators too, as long as it is > simpler. def view_decorator(fdec): def decorator(cls): original = cls.as_view.im_func @wraps(original) def as_view(current,

Re: ForbiddenMixin for Django?

On Feb 3, 2:16 pm, Russell Keith-Magee wrote: > On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen wrote: > The pair of Ls in my email address aren't just there for show. Russell. Two > Ls. I'm terribly sorry, that was unintentional. But I would be

Re: ForbiddenMixin for Django?

On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen wrote: > "Meh - this seems like reinventing a syntactic wheel to me. Python > 2.6 > has class decorators." - Russel The pair of Ls in my email address aren't just there for show. Russell. Two Ls. > Why to use decorators?

Re: r15401 and removing star imports

On 3 feb, 10:28, Florian Apolloner wrote: > I think the "url" function should get added to the imports > inhttp://code.djangoproject.com/changeset/15401since many people use it > by now. Any thoughts or objections? +1 on that, I think it would be beneficial even for

r15401 and removing star imports

Hi, I think the "url" function should get added to the imports in http://code.djangoproject.com/changeset/15401 since many people use it by now. Any thoughts or objections? Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: ForbiddenMixin for Django?

"Meh - this seems like reinventing a syntactic wheel to me. Python 2.6 has class decorators." - Russel Why to use decorators? They cannot be overridden neatly in subclasses, see my above gist about this subclassing. -- You received this message because you are subscribed to the Google Groups

Re: ForbiddenMixin for Django?

Here is now subclassed from View, and checked that overriding works: https://gist.github.com/809208 -- 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