Re: admin: implementing list_prefetch_related

[Riccardo Magliocchetti]

Hi Marc,

fine, was thinking on supporting just the simple case without the Prefetch 
object.

Il 31/12/2015 00:30, Marc Tamlyn ha scritto:

Hi Richard,

Overriding the queryset is a pretty simple method override, I'm not sure there
is sufficient need for prefetching here. In particular, the syntax for prefetch
related is much more complex than for select related, so it's less well suited
to this kind of shortcut.

Marc

On 30 Dec 2015 10:26 a.m., "Riccardo Magliocchetti"
mailto:riccardo.magliocche...@gmail.com>> 
wrote:

Hello,

the need to list an m2m relationship serialized in the admin list view
happens quite often to me and overriding the queryset may not be as trivial
as a ModelAdmin attribute. It makes sense to me to match what is possible
with foreign keys and list_select_related.
Any opinion on implementing list_prefetch_related for ModelAdmin?

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/5683B12D.6000600%40gmail.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/CAMwjO1ECoZGJEkGttZtAZeSBUktHRoYCX_hOj-1ehYtGCRSLzw%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.



--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/5684F8C0.1090805%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Jannis Leidel]

> On 29 Dec 2015, at 01:36, Tim Graham  wrote:
> 
> I'd like to work together with Dave to develop a proof of concept that 
> integrates whitenoise into Django. I spent about an hour looking through 
> whitenoise and our own static file serving code, and I think integrating 
> whitenoise will yield a simpler user experience with about the same amount of 
> code as have now.
> 
> Essentially, we'd recommend adding something like this to existing wsgi.py 
> files (it would be in the default startproject template)
> 
> from whitenoise.django import DjangoWhiteNoise
> application = DjangoWhiteNoise(application)
> application.add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)
> 
> which would have the benefit of working out of the box in production too, I 
> think. Of course, you could disable that based on settings.DEBUG or some 
> other toggle.
> 
> We could then deprecate:
> 
> * django/contrib/staticfiles/views.py
> * django/contrib/staticfiles/management/commands/runserver.py
> * django/contrib/staticfiles/handlers.py
> * django/views/static.py
> 
> Any objections to doing further investigation in this area?

None, this sounds like a great combination and a logical continuation of what I 
did back then with staticfiles.

The fact that staticfiles had all this custom logic to handle file serving in 
staticfiles was a necessary evil to stay backward compatible and lower the risk 
of staticfiles becoming a failure -- it wasn’t clear at all if it’d match the 
workflow for most of Django’s user base (and it still hasn’t completely I 
think). Whitenoise is agnostic enough about where the served files come from so 
this fits nicely.

> On Saturday, June 20, 2015 at 8:09:11 AM UTC-4, David Evans wrote:
> On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote:
> On 12/04/2014 10:33 PM, Collin Anderson wrote: 
> > Hi All, 
> > 
> > I'm pretty interested in getting secure and _somewhat_ efficient static 
> > file serving in Django. 
> > 
> > Quick history: 
> > 2005 - Jacob commits #428: a "static pages" view.  Note that this view 
> > should only be used for testing!" 
> > 2010 - Jannis adds staticfiles. Serving via django is considered "grossly 
> > inefficient and probably insecure". 
> > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn. 
> > 2012 - Aymeric adds StreamingHttpResponse and now files are read in chunks 
> > rather than reading the entire file into memory. (No longer grossly 
> > inefficient IMHO.) 
> > 
> > I propose: 
> > - Deprecate the "show_indexes" parameter of static.serve() (unless people 
> > actually use it). 
> > - Have people report security issues to secu...@djangoproject.com (like 
> > always) 
> > - Audit the code and possibly add more security checks and tests. 
> > - add wsgi.file_wrapper support to responses (5-line proof of concept: 
> > https://github.com/django/django/pull/3650 ) 
> > - support serving static files in production, but still recommend 
> > nginx/apache or a cdn for performance. 
> > - make serving static files in production an opt-in, but put the view in 
> > project_template/project_name/urls.py 
> > 
> > I think it's a huge win for low-traffic sites or sites in the "just trying 
> > to deploy and get something live" phase. You can always optimize later by 
> > serving via nginx or cdn. 
> > We already have the views, api, and logic around for finding and serving 
> > the correct files. 
> > We can be just as efficient and secure as static/dj-static without needing 
> > to make people install and configure wsgi middleware to the application. 
> > We could have staticfiles classes implement more complicated features like 
> > giving cache recommendations, and serving pre-gzipped files. 
> > 
> > Is this a good idea? I realize it's not totally thought through. I'm fine 
> > with waiting until 1.9 if needed. 
> 
> I also think this is a good plan. It certainly makes sense to look at 
> "static" and "whitenoise" for ideas and compare their code to ours to 
> see where we could be more efficient or secure, but it's much less churn 
> for Django users if we simply improve our existing code rather than pull 
> in something wholly new. 
> 
> Carl 
> 
> 
>  
> Sorry to revive an old thread here, but I just wanted to add that v2.0 of 
> WhiteNoise now supports serving development files, providing the same 
> behaviour as runserver currently does in DEBUG mode. (There were enough 
> people wanting to do their development using gunicorn rather than runserver 
> to make this worthwhile.)
> 
> This means that WhiteNoise is now a one-stop-shop for static file handling in 
> Django. If there's still an appetite for integrating it, or something 
> equivalent, into core I'd be happy to help out.
> 
> Dave
> 
> -- 
> 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+unsubsc

Re: delegating our static file serving

[Anssi Kääriäinen]

In my opinion one of the most important goals for Django is to make
deploying tiny projects securely and easily a trivial matter. We
aren't there right now.

If you have a site where traffic is less than one hit per minute, you
shouldn't care about performance that much.

With Django, it is pretty easy to write a decent "one-off" application
in an hour. Unfortunately, proper (that is, secure and automated)
deployment takes a lot longer than that.

Maybe part of the problem is that core developers tend to work on
larger sites, where you likely want a customized deployment anyways,
and working on deployment scripts doesn't take such a large portion of
the total time.

Anything that improves the development experience for tiny sites gets
a big +1 from me.

 - Anssi

On Thu, Dec 31, 2015 at 1:17 PM, Jannis Leidel  wrote:
>
>> On 29 Dec 2015, at 01:36, Tim Graham  wrote:
>>
>> I'd like to work together with Dave to develop a proof of concept that 
>> integrates whitenoise into Django. I spent about an hour looking through 
>> whitenoise and our own static file serving code, and I think integrating 
>> whitenoise will yield a simpler user experience with about the same amount 
>> of code as have now.
>>
>> Essentially, we'd recommend adding something like this to existing wsgi.py 
>> files (it would be in the default startproject template)
>>
>> from whitenoise.django import DjangoWhiteNoise
>> application = DjangoWhiteNoise(application)
>> application.add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)
>>
>> which would have the benefit of working out of the box in production too, I 
>> think. Of course, you could disable that based on settings.DEBUG or some 
>> other toggle.
>>
>> We could then deprecate:
>>
>> * django/contrib/staticfiles/views.py
>> * django/contrib/staticfiles/management/commands/runserver.py
>> * django/contrib/staticfiles/handlers.py
>> * django/views/static.py
>>
>> Any objections to doing further investigation in this area?
>
> None, this sounds like a great combination and a logical continuation of what 
> I did back then with staticfiles.
>
> The fact that staticfiles had all this custom logic to handle file serving in 
> staticfiles was a necessary evil to stay backward compatible and lower the 
> risk of staticfiles becoming a failure -- it wasn’t clear at all if it’d 
> match the workflow for most of Django’s user base (and it still hasn’t 
> completely I think). Whitenoise is agnostic enough about where the served 
> files come from so this fits nicely.
>
>> On Saturday, June 20, 2015 at 8:09:11 AM UTC-4, David Evans wrote:
>> On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote:
>> On 12/04/2014 10:33 PM, Collin Anderson wrote:
>> > Hi All,
>> >
>> > I'm pretty interested in getting secure and _somewhat_ efficient static
>> > file serving in Django.
>> >
>> > Quick history:
>> > 2005 - Jacob commits #428: a "static pages" view.  Note that this view
>> > should only be used for testing!"
>> > 2010 - Jannis adds staticfiles. Serving via django is considered "grossly
>> > inefficient and probably insecure".
>> > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
>> > 2012 - Aymeric adds StreamingHttpResponse and now files are read in chunks
>> > rather than reading the entire file into memory. (No longer grossly
>> > inefficient IMHO.)
>> >
>> > I propose:
>> > - Deprecate the "show_indexes" parameter of static.serve() (unless people
>> > actually use it).
>> > - Have people report security issues to secu...@djangoproject.com (like
>> > always)
>> > - Audit the code and possibly add more security checks and tests.
>> > - add wsgi.file_wrapper support to responses (5-line proof of concept:
>> > https://github.com/django/django/pull/3650 )
>> > - support serving static files in production, but still recommend
>> > nginx/apache or a cdn for performance.
>> > - make serving static files in production an opt-in, but put the view in
>> > project_template/project_name/urls.py
>> >
>> > I think it's a huge win for low-traffic sites or sites in the "just trying
>> > to deploy and get something live" phase. You can always optimize later by
>> > serving via nginx or cdn.
>> > We already have the views, api, and logic around for finding and serving
>> > the correct files.
>> > We can be just as efficient and secure as static/dj-static without needing
>> > to make people install and configure wsgi middleware to the application.
>> > We could have staticfiles classes implement more complicated features like
>> > giving cache recommendations, and serving pre-gzipped files.
>> >
>> > Is this a good idea? I realize it's not totally thought through. I'm fine
>> > with waiting until 1.9 if needed.
>>
>> I also think this is a good plan. It certainly makes sense to look at
>> "static" and "whitenoise" for ideas and compare their code to ours to
>> see where we could be more efficient or secure, but it's much less churn
>> for Django users if we simply improve our existing code rathe

Re: delegating our static file serving

[Guilherme Leal]

>>Anything that improves the development experience for tiny sites gets
>>a big +1 from me.

As a solo developer that usualy deploy a diferent application every 3 weeks
or so, cant agree more.

Big +1 for me too.

-- 
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/CAOs3Lp5RXYZA6aSA3gUkrwsGOM9a3ebMgAhG5DZZLy1GXyo2DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Aymeric Augustin]

2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen :

> In my opinion one of the most important goals for Django is to make
> deploying tiny projects securely and easily a trivial matter. We
> aren't there right now.
>

+1

I'm maintaining three such sites (my wife's, my consultancy's and mine). I'm
clearly not going to bother configuring a CDN. I deployed them with
whitenoise
— which isn't nearly as well known as it should be. If I hadn't known about
it, I suspect I would have rolled a poor man's solution to serve static
files
in Python, because that's the easiest when deploying to a PaaS.

Regarding the question of media files raised earlier in this thread, I think
we shouldn't attempt to cache all existing files on start-up because even
small sites could easily have tens of thousands e.g. a forum that stores
users' avatars. We should look up the file at each query, which will be
slightly less efficient, but functional and not subject to scalability
issues.

For both static and media files, we care about simplicity and security. It
appears that whitenoise gives us great performance for static files as well,
which is good. If we can't have it for media files, it's still fine.

-- 
Aymeric.

-- 
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/CANE-7mV_KwtmtgV9Oow4fgf9CaSPO4PsE_NL-NEqbOGC1kfk_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[Shai Berger]

On Wednesday 30 December 2015 08:40:17 martin f krafft wrote:
> also sprach Shai Berger  [2015-12-10 08:38 +1300]:
> > As far as I can see, you are trying to implement it in the model,
> > rather than as a new kind of field. Try to write
> > ExtendedGenericForeignKey, and I think things would look much
> > better...
> 
> Hi, thanks for your response and sorry for taking such a long time
> to follow-up.
> 
No need to apologize, we all have lives outside of Django...

> I've tried implementing this as a field at the very beginning, but
> I had an incredibly hard time figuring out which methods I need to
> provide. I don't suppose you know of any guidelines, other than the
> GenericForeignKey code (which I've still not fully understood) that
> could help?

Not really. I'd just advise you to use GenericForeignKey as a base class 
rather than a guideline.

Shai.

Re: Backwards-compatibility import shims

[Collin Anderson]

Hi All,

tldr: I think we should keep django.core.urlresolvers forever, or at least 
much much longer. Moving things to django.core.urls makes sense; removing 
the one line import shim from django.core.urlresolvers doesn't make sense 
to me.

General thoughts about compatibility, using this situation an example:

I think that if it's not broken, we should avoid breaking it. :) Some 
features are buggy or problematic or have bad api design and should be 
deprecated and removed. This is a simple rename so it only requires one 
file with one line of code (an import statement) to maintain full backwards 
compatibility here. Maybe we need also need a little doc stub saying that 
django.core.urlresolvers was renamed to django.core.urls and the new 
location is preferred. It seems to me when there's almost zero maintenance 
burden to not removing something, we shouldn't remove it, especially when 
it's an established and core api.

We have a stable api promise[1], and we should stick to it. "If, for some 
reason, an API declared stable must be removed or replaced, it will be 
declared deprecated but will remain in the API for at least two feature 
releases". I don't see this as a "must" situation.

There's enough changes to undocumented api's already happening that it 
would be great if the documented ones didn't change as much.

I hard code most of my urls, so it's only 41 lines of my code across 7 
projects of mine that would need to eventually get changed. Sure, it's a 
simple find and replace, but it's one more thing that almost every django 
project maintainer will need to eventually do.

Or, maybe I'm the the only one who thinks we deprecate and remove things 
too often. I feel like I ask for backwards compatibility a lot, even though 
I haven't been helping out with django as much as I used to.

Again, there's nothing specific about this case, there are plenty of other 
changes that I wish I noticed and spoke up about earlier: (assignment_tag, 
patterns(), django.conf.urls.defaults, generic.simple, etc).

And to be clear, some deprecations (like removing allow_tags) are really, 
really good. :)

Thanks,
Collin

[1] https://docs.djangoproject.com/en/dev/misc/api-stability/


On Wednesday, December 30, 2015 at 1:16:12 PM UTC-5, Michael Manfre wrote:
>
>
>
> On Wed, Dec 30, 2015 at 11:52 AM, Tim Graham  > wrote:
>
>> For that reason, I think we should reconsider making Django's deprecation 
>> warnings loud by default (at least in LTS versions) [1]. Otherwise, users 
>> will pester library authors to fix those warnings and we haven't really 
>> made things easier.
>>
>> Instead, the idea would be for library authors to continue using the 
>> deprecated APIs while supporting the LTS in which they are deprecated and 
>> the previous LTS. When the version of Django following the LTS is released, 
>> library authors can then drop support for all Django versions before the 
>> LTS, check their package with the LTS using python -Wall and make the 
>> deprecation warning fixes, then seamlessly add support for the next version 
>> of Django.
>>
>> Does that make sense?
>>
>
> This makes sense to me. +1
>
> Regards,
> Michael Manfre
>
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>

-- 
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/1f054b71-45f5-467f-a672-5ede9b785075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Collin Anderson]

I'm still +1 to django providing a good file solution, whether it be 
whitenoise, dj-static, or whatever.

Here's all I came up with the last time I looked into this. It basically 
involves passing insecure=True into our current code and sending cache 
headers. (I feel like the insecure flag could get renamed to inefficient or 
something like that.) I feel like the code we have really isn't all that 
bad. Using something like whitenoise or dj-static allows you to bypass 
middleware, which can really improve performance (if you have inefficient 
middleware installed), but on the other hand, some people may want to use 
the currently logged in user to determine whether or not to serve the file.

Collin

import re

from django.conf import settings
from django.conf.urls import url
from django.contrib.staticfiles.views import serve as static_serve
from django.core.exceptions import ImproperlyConfigured
from django.views.decorators.cache import cache_control
from django.views.static import serve


def static(prefix, view=serve, **kwargs):
if not prefix:
raise ImproperlyConfigured("Empty static prefix not permitted")
if '://' in prefix:
return []
if not settings.DEBUG:
view = cache_control(max_age=86400 * 30)(view)
return [
url(r'^%s(?P.*)$' % re.escape(prefix.lstrip('/')), view, 
kwargs=kwargs),
]

urlpatterns = static(settings.STATIC_URL, view=static_serve, insecure=True)

if settings.MEDIA_URL and settings.MEDIA_ROOT:
urlpatterns += static(settings.MEDIA_URL, document_root=settings.
MEDIA_ROOT)


On Thursday, December 31, 2015 at 7:42:54 AM UTC-5, Aymeric Augustin wrote:
>
> 2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen  >:
>
>> In my opinion one of the most important goals for Django is to make
>> deploying tiny projects securely and easily a trivial matter. We
>> aren't there right now.
>>
>
> +1
>
> I'm maintaining three such sites (my wife's, my consultancy's and mine). 
> I'm
> clearly not going to bother configuring a CDN. I deployed them with 
> whitenoise
> — which isn't nearly as well known as it should be. If I hadn't known about
> it, I suspect I would have rolled a poor man's solution to serve static 
> files
> in Python, because that's the easiest when deploying to a PaaS.
>
> Regarding the question of media files raised earlier in this thread, I 
> think
> we shouldn't attempt to cache all existing files on start-up because even
> small sites could easily have tens of thousands e.g. a forum that stores
> users' avatars. We should look up the file at each query, which will be
> slightly less efficient, but functional and not subject to scalability 
> issues.
>
> For both static and media files, we care about simplicity and security. It
> appears that whitenoise gives us great performance for static files as 
> well,
> which is good. If we can't have it for media files, it's still fine.
>
> -- 
> Aymeric.
>

-- 
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/9fd6dee0-3293-43bb-9eee-f281a7f14921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Fabio Caritas Barrionuevo da Luz]

A question: are there any plans to also improve MEDIA files (user uploaded 
files) in any foreseeable future?

Perhaps this is outside the scope of Django, but I believe Django could 
provide by default, any option to get a little more control over who can 
and can not access the MEDIA files.

Most Django deployment tutorials with Nginx and Apache that saw out there 
do not say anything on the issue of data security.

I believe it is a common use case, that not every file sent by a User 
should be available and accessible to anyone on the web.

Out there, I found these two implementations:

https://github.com/benoitbryon/django-downloadview

https://github.com/johnsensible/django-sendfile


-- 
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul

http://pythonclub.com.br/



Em quinta-feira, 31 de dezembro de 2015 19:44:01 UTC-3, Collin Anderson 
escreveu:
>
> I'm still +1 to django providing a good file solution, whether it be 
> whitenoise, dj-static, or whatever.
>
> Here's all I came up with the last time I looked into this. It basically 
> involves passing insecure=True into our current code and sending cache 
> headers. (I feel like the insecure flag could get renamed to inefficient or 
> something like that.) I feel like the code we have really isn't all that 
> bad. Using something like whitenoise or dj-static allows you to bypass 
> middleware, which can really improve performance (if you have inefficient 
> middleware installed), but on the other hand, some people may want to use 
> the currently logged in user to determine whether or not to serve the file.
>
> Collin
>
> import re
>
> from django.conf import settings
> from django.conf.urls import url
> from django.contrib.staticfiles.views import serve as static_serve
> from django.core.exceptions import ImproperlyConfigured
> from django.views.decorators.cache import cache_control
> from django.views.static import serve
>
>
> def static(prefix, view=serve, **kwargs):
> if not prefix:
> raise ImproperlyConfigured("Empty static prefix not permitted")
> if '://' in prefix:
> return []
> if not settings.DEBUG:
> view = cache_control(max_age=86400 * 30)(view)
> return [
> url(r'^%s(?P.*)$' % re.escape(prefix.lstrip('/')), view, 
> kwargs=kwargs),
> ]
>
> urlpatterns = static(settings.STATIC_URL, view=static_serve, insecure=True
> )
>
> if settings.MEDIA_URL and settings.MEDIA_ROOT:
> urlpatterns += static(settings.MEDIA_URL, document_root=settings.
> MEDIA_ROOT)
>
>
> On Thursday, December 31, 2015 at 7:42:54 AM UTC-5, Aymeric Augustin wrote:
>>
>> 2015-12-31 12:52 GMT+01:00 Anssi Kääriäinen :
>>
>>> In my opinion one of the most important goals for Django is to make
>>> deploying tiny projects securely and easily a trivial matter. We
>>> aren't there right now.
>>>
>>
>> +1
>>
>> I'm maintaining three such sites (my wife's, my consultancy's and mine). 
>> I'm
>> clearly not going to bother configuring a CDN. I deployed them with 
>> whitenoise
>> — which isn't nearly as well known as it should be. If I hadn't known 
>> about
>> it, I suspect I would have rolled a poor man's solution to serve static 
>> files
>> in Python, because that's the easiest when deploying to a PaaS.
>>
>> Regarding the question of media files raised earlier in this thread, I 
>> think
>> we shouldn't attempt to cache all existing files on start-up because even
>> small sites could easily have tens of thousands e.g. a forum that stores
>> users' avatars. We should look up the file at each query, which will be
>> slightly less efficient, but functional and not subject to scalability 
>> issues.
>>
>> For both static and media files, we care about simplicity and security. It
>> appears that whitenoise gives us great performance for static files as 
>> well,
>> which is good. If we can't have it for media files, it's still fine.
>>
>> -- 
>> Aymeric.
>>
>

-- 
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/6b3b995c-ca28-4a61-a8b6-023314ca8b70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.