On 14/04/16 05:57, Carl Meyer wrote:
Hi James et al,
In general, I like the idea of adding a helper to Django to read
settings from the environment. I think this helper should be kept as
simple and non-magical as is reasonable. Thus:
- I'm in favor of a flexible helper function that can be
Thanks Tim for the info.
This is the discussion mentioned in the ticket (from
2012) https://groups.google.com/d/topic/django-developers/vtMVq8jwnf8/discussion
The solutions that ptone suggests in the ticket don't really work for
Heroku. Also, to sync static files from local is not a good
During a review session I noticed the existence of `DjangoRuntimeWarning`[1]
which was introduced in order to be subclassed to warn about about cache
keys
that are not compatible with Memcache[2].
As our test suite demonstrate subclassing `RuntimeWarning` can be quite
useful
when you want to
I have a small concern.
The two new settings looks like will work on uploaded files count
(multipart encoding types) and number of fields sent (url encoded
encoding). What happens to other request types such as JSON, XML, plain
text etc... If you are using django-rest-framework, how would the
Django 1.7 realease JsonResponse subclass of HttpResponse helps easily
create JSON-encoded responses.
As discussed in https://code.djangoproject.com/ticket/17942#comment:6
- Trying to support JSONP callbacks would require to somehow allow
Cross-origin resource sharing. I would say it's
Would it be better to add an optional parameter to the constructor of
JsonResponse instead of a new subclass?
On 16 Apr 2016 12:06 PM, wrote:
> Django 1.7 realease JsonResponse subclass of HttpResponse helps easily
> create JSON-encoded responses.
>
> As discussed in