Re: Adding sanity to an error message if HttpResponse is not returned from a view.

[Russell Keith-Magee]

Hi Justin,

On Tue, Sep 23, 2014 at 7:10 AM, Justin Holmes 
wrote:

> Currently, we perform a sanity check to provide a useful error message
> if a view returns None:
>
>
> https://github.com/django/django/blob/1101467ce0756272a54f4c7bc65c4c335a94111b/django/core/handlers/base.py#L138
>
> However, if a view returns a different object (say, a string), we
> don't have a similarly useful message.
>
> This is a very common newcomer mistake, and it causes immense frustration.
>
> I have just had a third student encounter this problem and feel
> completely blocked by it, so I think it's time to bring it to the
> list.
>
> I suggest that we add a try block, catching AttributeError, and
> wrapping it, adding to the beginning of the message, "The object
> returned by the view was not compatible with the Django http
> subsystem.  Remember: views must return HttpResponse objects."
>
> Also, similar to the new error messages accompanying the app object, I
> want to suggest that we add a link to the document describing this.
>
> I imagine that this has been a discussion before, but I can't find a
> ticket.  Is there one?
>

Not that I can recall. I think it's one of those ideas that's just so
obvious, nobody thought to report it before :-)

I can't think of any reason why what you propose would be a bad idea.

I don't think that big of a change is required in the error message, though
- the current message is fine, as long as you replace "none" with
"type(response)", along with protection for the case where a HttpReponse
*is* returned, but has internally raised an AttributeError:

try:
(...handle response)
except AttributeError:
if isinstance(response, HttpResponse):
raise
raise ValueError('The view %s.%s didn't return an HttpResponse object.
It returned %s instead."
 % (callback.__module__, view_name,
type(response)))

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84_zHrZS3g8ujfmzA8XJT1snS7gUaDLjNf-yi00h%2Bt4Weg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTTP/2 and WSGI

[Collin Anderson]

On Saturday, September 20, 2014 12:25:02 PM UTC-4, Ryan Hiebert wrote:
>
> Being the idealist I am, I hope we can find a way to rid ourselves of the 
> pain of cgi. I'd be more than willing to help, but my help would probably 
> be more of a hindrance because of the limited exposure I've had with 
> developing wsgi. However, I did want to register my support to those 
> looking to change things.
>
 
I wouldn't mind working with lowercased headers, personally. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a69ff944-8fbf-44eb-bcb3-5abc59be5f85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: squashmigrations missing a simple optimization?

[Shai Berger]

Replying to myself:

On Sunday 21 September 2014 20:59:46 Shai Berger wrote:
> Hi,
> 
> I'm looking into the details of migrations a little, and I ran into this
> issue.
> 
> I have two migrations: The first creates a model, the second adds another
> model and a field to the first model. I'd expect squashmigrations to patch
> the AddField into the first CreateModel, but it finds "No optimizations
> possible". What am I missing?
> 

Yesterday-self is missing that foreign keys (seem to be) always added in 
separate operations. This makes it easy to resolve reference loops.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201409221004.44992.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.