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

[Tai Lee]

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 to Django under Apache/mod_wsgi.

Cheers.
Tai.


On Feb 4, 6:17 pm, Graham Dumpleton 
wrote:
> 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
> description could be on all WSGI hosting mechanisms, and then just hope that
> there aren't other reasons why it could arise from WSGI middleware.
>
> So, no simple solution. This unfortunately is one of the short comings of
> the WSGI specification. That is, there is no standardised exception type to
> represent actual real problems with reading original wsgi.input. Part of the
> reason is that there is no standard module associated with the WSGI
> specification to hold the exception type, so nothing to compare against. The
> only solution would be for WSGI specification to be enhanced to require a
> unique exception type to be used for wsgi.input exceptions such as aborted
> connection, with the type of that exception being passed through in the WSGI
> environ dictionary so it could be compare against. For example something
> like:
>
>   try:
>     data = environ['wsgi.input'].read()
>   except wsgi['wsgi.input_exception], e:
>     # ignore it
>
> In summary, no real practical solution at this time for this.
>
> Graham
>
>
>
>
>
>
>
> On Friday, February 4, 2011 1:55:25 PM UTC+11, Tai Lee wrote:
>
> > 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 with large and small uploads alike, but always
> > intermittently.
>
> > It has been suggested that a client dropping the connection should be
> > within what one can expect from a networked client, and thus Django
> > should not email the exception and traceback to the admins in this
> > case. From my preliminary investigation with this issue, I tend to
> > agree.
>
> > Is it feasible to handle this exception in Django, or are there other
> > issues that would prevent us from isolating this case from other
> > legitimate exceptions that may be raised at this point?
>
> > Here's a recent traceback:
>
> > Traceback (most recent call last):
>
> >  File "/home/tailee/django/core/handlers/base.py", line 105, in
> > get_response
> >    response = middleware_method(request, callback, callback_args,
> > callback_kwargs)
>
> >  File "/home/tailee/django/middleware/csrf.py", line 224, in
> > process_view
> >    request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
>
> >  File "/home/tailee/django/core/handlers/wsgi.py", line 209, in
> > _get_post
> >    self._load_post_and_files()
>
> >  File "/home/tailee/django/http/__init__.py", line 207, in
> > _load_post_and_files
> >    self._post, self._files = self.parse_file_upload(self.META, self)
>
> >  File "/home/tailee/django/http/__init__.py", line 169, in
> > parse_file_upload
> >    return parser.parse()
>
> >  File "/home/tailee/django/http/multipartparser.py", line 192, in
> > parse
> >    for chunk in field_stream:
>
> >  File "/home/tailee/django/http/multipartparser.py", line 314, in next
> >    output = self._producer.next()
>
> >  File "/home/tailee/django/http/multipartparser.py", line 468, in next
> >    for bytes in stream:
>
> >  File "/home/tailee/django/http/multipartparser.py", line 314, in next
> >    output = self._producer.next()
>
> >  File "/home/tailee/django/http/multipartparser.py", line 375, in next
> >    data = self.flo.read(self.chunk_size)
>
> >  File "/home/tailee/django/http/multipartparser.py", line 405, in read
> >    return self._file.read(num_bytes)
>
> >  File "/home/tailee/django/http/__init__.py", line 231, in read
> >    return self._stream.read(*args, **kwargs)
>
> > IOError: request data read error

-- 
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: Feature request: Abstract ManyToManyField

[Gert Van Gool]

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
> 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 Admin insertion of the relationships (without
> resorting to InLines, which don't seem to play nicely at all with
> FieldSets).  Right now I'm getting around the problem by running
> syncdb, running dbshell to drop the table it complains about, and
> rerunning syncdb; repeating until syncdb finishes successfully.
>
> What would make this exceptionally easy, is if there was the option to
> set 'abstract=True' on second iteration of each of the
> ManyToManyFields, telling syncdb to not attempt to create it.
>
> Thoughts?
>
> --
> Mike Lindsey
>
> --
> 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: Intermittent IOError exception raised and emailed to admins during file upload.

[Graham Dumpleton]

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 
description could be on all WSGI hosting mechanisms, and then just hope that 
there aren't other reasons why it could arise from WSGI middleware.

So, no simple solution. This unfortunately is one of the short comings of 
the WSGI specification. That is, there is no standardised exception type to 
represent actual real problems with reading original wsgi.input. Part of the 
reason is that there is no standard module associated with the WSGI 
specification to hold the exception type, so nothing to compare against. The 
only solution would be for WSGI specification to be enhanced to require a 
unique exception type to be used for wsgi.input exceptions such as aborted 
connection, with the type of that exception being passed through in the WSGI 
environ dictionary so it could be compare against. For example something 
like:

  try:
data = environ['wsgi.input'].read()
  except wsgi['wsgi.input_exception], e:
# ignore it

In summary, no real practical solution at this time for this.

Graham

On Friday, February 4, 2011 1:55:25 PM UTC+11, Tai Lee wrote:
>
> 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 with large and small uploads alike, but always 
> intermittently. 
>
> It has been suggested that a client dropping the connection should be 
> within what one can expect from a networked client, and thus Django 
> should not email the exception and traceback to the admins in this 
> case. From my preliminary investigation with this issue, I tend to 
> agree. 
>
> Is it feasible to handle this exception in Django, or are there other 
> issues that would prevent us from isolating this case from other 
> legitimate exceptions that may be raised at this point? 
>
> Here's a recent traceback: 
>
> Traceback (most recent call last): 
>
>  File "/home/tailee/django/core/handlers/base.py", line 105, in 
> get_response 
>response = middleware_method(request, callback, callback_args, 
> callback_kwargs) 
>
>  File "/home/tailee/django/middleware/csrf.py", line 224, in 
> process_view 
>request_csrf_token = request.POST.get('csrfmiddlewaretoken', '') 
>
>  File "/home/tailee/django/core/handlers/wsgi.py", line 209, in 
> _get_post 
>self._load_post_and_files() 
>
>  File "/home/tailee/django/http/__init__.py", line 207, in 
> _load_post_and_files 
>self._post, self._files = self.parse_file_upload(self.META, self) 
>
>  File "/home/tailee/django/http/__init__.py", line 169, in 
> parse_file_upload 
>return parser.parse() 
>
>  File "/home/tailee/django/http/multipartparser.py", line 192, in 
> parse 
>for chunk in field_stream: 
>
>  File "/home/tailee/django/http/multipartparser.py", line 314, in next 
>output = self._producer.next() 
>
>  File "/home/tailee/django/http/multipartparser.py", line 468, in next 
>for bytes in stream: 
>
>  File "/home/tailee/django/http/multipartparser.py", line 314, in next 
>output = self._producer.next() 
>
>  File "/home/tailee/django/http/multipartparser.py", line 375, in next 
>data = self.flo.read(self.chunk_size) 
>
>  File "/home/tailee/django/http/multipartparser.py", line 405, in read 
>return self._file.read(num_bytes) 
>
>  File "/home/tailee/django/http/__init__.py", line 231, in read 
>return self._stream.read(*args, **kwargs) 
>
> IOError: request data read error 
>

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

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

[Tai Lee]

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 with large and small uploads alike, but always
intermittently.

It has been suggested that a client dropping the connection should be
within what one can expect from a networked client, and thus Django
should not email the exception and traceback to the admins in this
case. From my preliminary investigation with this issue, I tend to
agree.

Is it feasible to handle this exception in Django, or are there other
issues that would prevent us from isolating this case from other
legitimate exceptions that may be raised at this point?

Here's a recent traceback:

Traceback (most recent call last):

 File "/home/tailee/django/core/handlers/base.py", line 105, in
get_response
   response = middleware_method(request, callback, callback_args,
callback_kwargs)

 File "/home/tailee/django/middleware/csrf.py", line 224, in
process_view
   request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')

 File "/home/tailee/django/core/handlers/wsgi.py", line 209, in
_get_post
   self._load_post_and_files()

 File "/home/tailee/django/http/__init__.py", line 207, in
_load_post_and_files
   self._post, self._files = self.parse_file_upload(self.META, self)

 File "/home/tailee/django/http/__init__.py", line 169, in
parse_file_upload
   return parser.parse()

 File "/home/tailee/django/http/multipartparser.py", line 192, in
parse
   for chunk in field_stream:

 File "/home/tailee/django/http/multipartparser.py", line 314, in next
   output = self._producer.next()

 File "/home/tailee/django/http/multipartparser.py", line 468, in next
   for bytes in stream:

 File "/home/tailee/django/http/multipartparser.py", line 314, in next
   output = self._producer.next()

 File "/home/tailee/django/http/multipartparser.py", line 375, in next
   data = self.flo.read(self.chunk_size)

 File "/home/tailee/django/http/multipartparser.py", line 405, in read
   return self._file.read(num_bytes)

 File "/home/tailee/django/http/__init__.py", line 231, in read
   return self._stream.read(*args, **kwargs)

IOError: request data read error

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

[Karen Tracey]

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 way an "empty value."
>
> From the point of view of the model layer, your point makes sense.
> However, I think the UI is the challenge. This would force every
> BooleanField to have a drop-down (like NullBooleanField) instead of a
> checkbox, at least on the /add/ forms.
>
>
No, that problem is already handled by the CheckboxInput widget (
http://docs.djangoproject.com/en/dev/topics/db/models/#field-name-hiding-is-not-permitted),
which forces "no value" to False. We're not relying on the model-level False
default to get check boxes to work properly.

Karen
-- 
http://tracey.org/kmt/

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

[Richard Laager]

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 sense.
However, I think the UI is the challenge. This would force every
BooleanField to have a drop-down (like NullBooleanField) instead of a
checkbox, at least on the /add/ forms.

Richard


signature.asc
Description: This is a digitally signed message part

Feature request: Abstract ManyToManyField

[Mike Lindsey]

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 Admin insertion of the relationships (without
resorting to InLines, which don't seem to play nicely at all with
FieldSets).  Right now I'm getting around the problem by running
syncdb, running dbshell to drop the table it complains about, and
rerunning syncdb; repeating until syncdb finishes successfully.

What would make this exceptionally easy, is if there was the option to
set 'abstract=True' on second iteration of each of the
ManyToManyFields, telling syncdb to not attempt to create it.

Thoughts?

--
Mike Lindsey

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

[Tobias McNulty]

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
> > > instance that has no value set is what's being asked for. The quiet
> always
> > > defaulting to False does seem rather odd to me as well.
> >
> > The current behaviour still seems in-line with the behaviour a
> non-nullable
> > charfield (if not self.null, default to '').
> > So, for consistency should we also make a not-null charfield fail loudly
> if
> > instanciated without a value ? :P
>
> My argument for that is on the ticket. "It's ok for CharFields with
> blank=True to default to the empty string, because that's semantically
> the lack of a value for the field. However, True and False are equals;
> False is not the lack of a value."


Whoops, looks like I should have refreshed this thread before hitting send.
 :-)

Tobias
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Ticket #15124: BooleanField should not use False as default (unless provided)

[Tobias McNulty]

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 always
>> defaulting to False does seem rather odd to me as well.
>>
>
> The current behaviour still seems in-line with the behaviour a non-nullable
> charfield (if not self.null, default to '').
> So, for consistency should we also make a not-null charfield fail loudly if
> instanciated without a value ? :P
>

Really?  Django makes the case[1] that "" means "no data" for char and text
fields, as does None for integers, dates, and booleans.  As far as I can
tell, the behavior of all fields, except for BooleanField, is to default to
the empty value supported by that field.  Personally I see nothing wrong
with that (though I suppose a case could be made against the "" default for
CharFields, if someone wanted to).  On the other hand, False is in no way an
"empty value."  The flip side of the question is, given the current behavior
of BooleanFields, should we also make all not-null IntegerFields default to
0?

Tobias

[1] http://docs.djangoproject.com/en/dev/ref/models/fields/#null
-- 
Tobias McNulty, Managing Partner
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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: Error: cannot import name SpooledTemporaryFile

[Sergiy Kuzmenko]

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 , 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 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: Ticket #15124: BooleanField should not use False as default (unless provided)

[anb]

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
> > defaulting to False does seem rather odd to me as well.
>
> The current behaviour still seems in-line with the behaviour a non-nullable
> charfield (if not self.null, default to '').
> So, for consistency should we also make a not-null charfield fail loudly if
> instanciated without a value ? :P

My argument for that is on the ticket. "It's ok for CharFields with
blank=True to default to the empty string, because that's semantically
the lack of a value for the field. However, True and False are equals;
False is not the lack of a value."

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

Error: cannot import name SpooledTemporaryFile

[b...@live.se]

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 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: ForbiddenMixin for Django?

[Łukasz Rekucki]

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 from my experience, but I may be biased.

>
> That could lead to following annoying situations: Base classes could
> e.g. enforce using some requirement for User.user_permission and
> subclass could require using per object permission. What would happen
> now? The programmer could not subclass from that class only because
> the permissions checking is enforced in super class but otherwise a
> good class, not exactly a good solution.

Which is an argument against putting permission checks into generic
reusable views, just like the current views don't use the
TemplateMixin by default (well, they do, but they have a Base*
duplicates). I'm not saying, that having a permission checking mixin
is a bad idea, but I don't like the proposed API. For starters, you
mentioned "object permissions" - how do I check that in your
implementation, if all checkers are evaluated in dispatch() (and
without fetching the object multiply times) ?

> So I think the overriding ability in subclasses is a good to have.

Ok, but I rather override some methods then a list.

>
> On Feb 3, 6:15 pm, Lukasz Rekucki  wrote:
>> On 3 February 2011 16:09, Jari Pennanen  wrote:
>> If they're not decorators, then that's even worse, 'cause you need to
>> duplicate all existing permission checking decorators.
>
> In fact current decorator permission checking mechanism is wrong, it
> does two things in one function: Checking permissions from request
> (what I propose to separate) and being decorator at the same time.
> They break the principle of one function one task, and should be
> breaken apart to checker functions and decorators. Similarly as
> validator functions are separated and reusable.

It's actually a shortcut for user_passes_test() decorator factory and
a very short lambda, so there is not much to reuse (apart from the
redirection code maybe).

> Making the attribute to *add only* is possible (but I don't support
> that because of need to override I said above), by iterating over
> classes (in __mro__*) and combining the checker functions to one list.

Yes, I know it's possible and I even showed you that exact
implementation. It's not exactly "add only" as you can always override
`get_decorators()` to filter out or replace the list entirely.

> However I find that would be odd behavior for class/instance
> attribute. Also programmer should be able to remember all the checker
> functions in all superclasses, and the overriding the earlier values
> becomes impossible (or requires other way to do it).

Without the add semantics, every time I want to add a check, I need to
repeat all the checks in base classes, which is not very DRY if you
ask me. If the checks come from a 3rd party app and it ever changes, I
would need to go through all my code and update the lists.

Maybe your mixin could provide a method to run the checks (so the view
can decide when to invoke it) and some other methods which do the
actual checks that can be overridden. Just a thought.

-- 
Łukasz Rekucki

-- 
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: ForbiddenMixin for Django?

[Jari Pennanen]

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 User.user_permission and
subclass could require using per object permission. What would happen
now? The programmer could not subclass from that class only because
the permissions checking is enforced in super class but otherwise a
good class, not exactly a good solution.

So I think the overriding ability in subclasses is a good to have.

On Feb 3, 6:15 pm, Lukasz Rekucki  wrote:
> On 3 February 2011 16:09, Jari Pennanen  wrote:
> If they're not decorators, then that's even worse, 'cause you need to
> duplicate all existing permission checking decorators.

In fact current decorator permission checking mechanism is wrong, it
does two things in one function: Checking permissions from request
(what I propose to separate) and being decorator at the same time.
They break the principle of one function one task, and should be
breaken apart to checker functions and decorators. Similarly as
validator functions are separated and reusable.

This is what I said in my ticket that *checker* functions are reusable
in decorators (not otherway around.)

> things like `template_name` or `model` just overwrite whatever was
> previously defined in the base classes. In case of permission checks,
> you will most likely want to *add* checks, not overwrite. Also, if I
> have 2 views/mixins that do some checks (which most likely are
> required for proper operation of those views/mixins), then if I
> inherit from both, my subclass should do all those checks, not only
> part of them.

Making the attribute to *add only* is possible (but I don't support
that because of need to override I said above), by iterating over
classes (in __mro__*) and combining the checker functions to one list.
However I find that would be odd behavior for class/instance
attribute. Also programmer should be able to remember all the checker
functions in all superclasses, and the overriding the earlier values
becomes impossible (or requires other way to do it).

*One can iterate over classes in mro order using e.g. inspect.getmro().

-- 
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: ForbiddenMixin for Django?

[Łukasz Rekucki]

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, **initkwargs):
return fdec(original(current, **initkwargs))
cls.as_view = classonlymethod(as_view)
return cls
return decorator

Using this transformer, you can decorate classes just like normal
views. It's simple and not-magical. The only drawback is that it
modifies the given class, so it can't be used "in-place", so it didn't
make it (Although, I'm using it quite successfully for some time now
in my projects and we didn't had any trouble with it yet). Other
version was to create a subclass "on-the-fly", but it turned out to be
even more dangerous.

>
> This forbidden_checks is not list of decorators, just functions that
> checks the request/input if the view is allowed to view.

If they're not decorators, then that's even worse, 'cause you need to
duplicate all existing permission checking decorators.

> Secondly why
> couldn't there be get_forbidden_checks() getter too if that is the
> problem?

Something similar was already proposed earlier by Luke Plant and I
made an example implementation that takes MRO into account:
https://github.com/lqc/django/commit/ef7a7adfb72c79e4c0068841e4b71ac27c138b28

It does work quite nicely, but as Russell said - it's a magic
attribute, a bit like the Meta class in models, but worse as it
duplicates the idea of class decorators.

>
> I personally don't find this behavior surprising. If there really is
> something fundamentally different with forbidden_checks and other
> class attributes like model, queryset, template_name,
> context_object_name, ... then there has to be a way to define the
> difference.

things like `template_name` or `model` just overwrite whatever was
previously defined in the base classes. In case of permission checks,
you will most likely want to *add* checks, not overwrite. Also, if I
have 2 views/mixins that do some checks (which most likely are
required for proper operation of those views/mixins), then if I
inherit from both, my subclass should do all those checks, not only
part of them.

-- 
Łukasz Rekucki

-- 
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: ForbiddenMixin for Django?

[Jari Pennanen]

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 happy for class decorators too, as long as it is
simpler.

> To my mind, this isn't quite the same as setting template_name. That's
> a simple configuration issue, not something that fundamentally alters
> view behavior. To reinforce the point -- as an alternative to
> specifying template_name, you can override the function
> get_template_names() which programatically returns the right template.
> It would strike me as strange for the list of decorators to be applied
> to a view to be configured in the same way. Yet it would be
> contradictory to have some class variables extendable by function, but
> not others.

This forbidden_checks is not list of decorators, just functions that
checks the request/input if the view is allowed to view. Secondly why
couldn't there be get_forbidden_checks() getter too if that is the
problem?

I personally don't find this behavior surprising. If there really is
something fundamentally different with forbidden_checks and other
class attributes like model, queryset, template_name,
context_object_name, ... then there has to be a way to define the
difference.

I can't see those other attributes any less important, shit will break
if one changes them unless changing other parts too (usually).

-- 
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: ForbiddenMixin for Django?

[Russell Keith-Magee]

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? They cannot be overridden neatly in subclasses,
> see my above gist about this subclassing.

Why use decorators? Because they're an established pattern. They're
conceptually well aligned -- take this existing thing, and wrap it
with this extra logic. And using decorators for this purpose is a
usage that already has precedent for exactly this purpose with
function-based views.

The catch is that it isn't easy to build a decorator that does what we
need it to do.

My problem with the approach you're describing is that I don't see
that it has precedent. Part of good API design is that it isn't
surprising. Why is a randomly named class variable the right place to
define the list of decorators that will be invoked before a dispatch?
What analogs exist in Django, or the wider Python community, that
would point to changing behavior based upon the value stored in a
class variable.

To my mind, this isn't quite the same as setting template_name. That's
a simple configuration issue, not something that fundamentally alters
view behavior. To reinforce the point -- as an alternative to
specifying template_name, you can override the function
get_template_names() which programatically returns the right template.
It would strike me as strange for the list of decorators to be applied
to a view to be configured in the same way. Yet it would be
contradictory to have some class variables extendable by function, but
not others.

I'm not saying I have a a better alternative waiting to be used -- I'm
just letting you know why I feel a design decision is required.

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: r15401 and removing star imports

[bpeschier]

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 beginners to see
url included, it makes naming urls cleaner and naming/reversing is
getting more important imho because of CBV.

Bas

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

r15401 and removing star imports

[Florian Apolloner]

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.
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: ForbiddenMixin for Django?

[Jari Pennanen]

"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 
"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: ForbiddenMixin for Django?

[Jari Pennanen]

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