Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

[Yoong Kang Lim]

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 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 not needed for most use
>cases.
>
>
> JsonpResponse isn't needed for most use cases. But is needed for some use
> cases.
>
> What do you think about adding JsonpResponse subclass of HttpResponse.
>
> The pr is https://github.com/django/django/pull/6455
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/00730c97-df1c-4dc9-9594-506f01988240%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKL8yL6cMfMnsrwmb%2BJ-PfeiGiNY9waAUEZ-1wyApVZWNar4CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

[brightcells]

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 not needed for most use 
   cases.
   

JsonpResponse isn't needed for most use cases. But is needed for some use 
cases.

What do you think about adding JsonpResponse subclass of HttpResponse.

The pr is https://github.com/django/django/pull/6455

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/00730c97-df1c-4dc9-9594-506f01988240%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

[Cristiano Coelho]

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 fields 
counter work?. It would be a shame if only multi part and urlencoded 
uploads would have the benefit of these checks, while still allowing json, 
xml and others still be "exploited".
Note I didn't really read the code changes completely so I'm talking with 
almost no knowledge on the proposed change.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/020adda9-93d5-4202-90b0-ac5a401ca85c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Usage of DjangoRuntimeWarning

[charettes]

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 consider some of them as errors[3] or simply ignore them. 
I'm
sure some of you will remember the pesky naive datetime warnings that were
raised when using the SQLite3 backend with IPython when timezone support was
introduced.

While reviewing a proposed change where I suggested introducing another
`DjangoRuntimeWarning` just like we do with the cache key warning Claude 
noted
that we should always use such a patten or simply drop it[4] as a quick
`grep RuntimeWarning django -r` revealed the cache key warning was the only
occurence of `DjangoRuntimeWarning`.

While I don't think subclassing `DjangoRuntimeWarning` for every internal 
use of
`warnings.warn` is required I believe using `DjangoRuntimeWarning` instead 
of
`RuntimeWarning` would make sense.

Thoughts?

Simon

[1] 
https://github.com/django/django/blob/74675a15d04260e8def7303e1d7a1425b6043b6c/django/core/exceptions.py#L13-L14
[2] 
https://github.com/django/django/commit/fc26da645aea2361d78cf5a5543214a240d82527
[3] https://github.com/django/django/blob/master/tests/runtests.py#L25-L26
[4] 
https://github.com/django/django/pull/6384/files/49a9a4c522e7733be7dc9d3d3f66a422731898e9#r59893575

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b3c17fea-3d1d-4307-ab53-10c1f8b1e476%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Collectstatic and determine which files need to be updated by comparing their checksum

[Daniel Blasco]

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 solution for 
example when using CI. And still there's the situation when trying to 
upload old files, like for example during a rollback.

At the end, the main problem is that collectstatic is using two different 
backends. One is being provided by each of the static file finders 
(settings.STATICFILE_FINDERS) and the other one is the one defined in 
settings.STATICFILES_STORAGE. As there's not a standard hash method, the 
Storage superclass can't force to implement a standard hash method for all 
its subclasses. 

Maybe a solution would be to shift the responsibility of detecting a file 
change from collectstatic to the STATICFILES_STORAGE? In this way we 
provide the flexibility of letting the Storage subclasses to decide how 
they want to check if a file has changed, they can use any technique they 
like and keep consistent.

A rough and simplified example:

# django/core/files/storage.py
class Storage(object):
def has_changed(self, source_storage, source_path, path):
raise NotImplementedError()


class FileSystemStorage(Storage):
def has_changed(self, source_storage, source_path, path):
return source_storage.modified_time(source_path) > 
self.modified_time(path)


# django/contrib/staticfiles/management/commands/collectstatic.py
class Command(BaseCommand):
def delete_file(self, path, prefixed_path, source_storage):
if self.storage.has_changed(source_storage, path, prefixed_path):
self.storage.delete(prefixed_path)


And then, anyone could do this in their own project (or even in 
django-storages):

# my_app/storages/custom_s3_storage.py
class MyStorage(S3BotoStorage):
def has_changed(self, source_storage, source_path, path):
try:
local_md5 = source_storage.get_md5(source_path)
except (NotImplementedError, AttributeError):
with source_storage.open(source_path) as source_file:
local_md5 = hashlib.md5(source_file.read()).hexdigest()

return self.get_md5(path) != local_md5

def get_md5(self, path):
return self.bucket.get_key(path).md5



It keeps backward compatibility and allows the possibility to use any 
comparison method by any Storage subclass.





On Friday, April 15, 2016 at 1:34:19 AM UTC+1, Tim Graham wrote:
>
> A proposal to use checksums was closed as wontfix in 
> https://code.djangoproject.com/ticket/19021.
>
> On Thursday, April 14, 2016 at 1:16:39 PM UTC-4, bliy...@rentlytics.com 
> wrote:
>>
>> This makes a lot of sense to me.
>>
>> On Tuesday, April 12, 2016 at 9:07:51 AM UTC-7, Daniel Blasco wrote:
>>>
>>> Hi,
>>>
>>> I posted this in django-users but I think that it goes better here.
>>>
>>>
>>> I'm using django-storages to upload my static files to Amazon S3 and I'm 
>>> serving my application from Heroku.
>>>
>>> In my local development, when I run collectstatic for a second time just 
>>> after the first one, no files are being uploaded to S3 because 
>>> collectstatic checks for the modified_time to determine if the local files 
>>> are newer than the ones in S3. That's fine so far.
>>>
>>> The problem is when I deploy to Heroku. Collectstatic is being executed 
>>> from the Heroku server and absolutely all the files are always being 
>>> uploaded to S3, even the ones that have not changed. This is because during 
>>> the deployment Heroku creates a full copy of the source code, and therefore 
>>> all the files have a new modified_time. In my case, it takes almost 10 
>>> minutes to upload ~1000 files for each deployment.
>>>
>>> Also, imagine the situation where the modified_times are not being 
>>> changed and I wanted to upload older versions of the static files. I wont 
>>> be able because storage wouldn't allow to upload files with an older 
>>> modified_time.
>>>
>>> I think that a more accurate way to check if a file needs to be replaced 
>>> could be by comparing their checksum/hash and offer this feature for all 
>>> the Storage subclasses. To preserve backwards compatibility, in 
>>> collectstatic command first determine if the storage subclass implements a 
>>> checksum generation and otherwise fallback to modified_time comparison.
>>>
>>>
>>> What do you think, is this something that makes sense?
>>>
>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: Making Django more PaaS-friendly

[Curtis Maloney]

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 manually used
in a settings file to read an explicitly-named env var and coerce it
using any arbitrary callable (that gives enough power to "coerce" using
something as simple as `int` or something as complex as
`parse_database_url` that turns a DSN string into a Django db dict),
with some handling of defaults. Below I give some usage examples of the
function I use for that, and link to its code.


+1

This I've found works well in d-c-s...


- I'm opposed to anything more magical than that, e.g. anything that
tries to set up an all-dancing automatic mapping or translation between
env var names and setting names, or tries to enforce some particular env
var prefix. The minor gains in conciseness with this kind of thing
aren't nearly worth the losses in flexibility in how you construct your
settings file or name your env vars.


+1

Adding more policy will only complicate matters... if you just provide 
the mechanism, people will surprise you with innovative policies :)



- I'm also opposed to conflating the issue of reading env vars with
orthogonal stuff like class-based settings or patterns for using
multiple settings files.


+1

Once again, there's no need to dictate more than necessary.

--
C

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57108E2C.9050803%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.