Loading lzma compressed fixtures

[Paolo Melchiorre]

Hi all,

Working at my latest merged PR [1] in Django I saw in the code the lack 
of support for lzma compressed fixture for loaddata command so I opened 
a ticket [2] and a related PR [3].


I think is a small PR to accept before Django 3.1 feature freeze but it 
can be a great improvement in loading big fixtures.


I would ask someone to review my PR [3].

Thanks,
Paolo


[1] https://github.com/django/django/pull/12871
[2] https://code.djangoproject.com/ticket/31552
[3] https://github.com/django/django/pull/12879

--
https://www.paulox.net

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8893560-de46-05d2-66d9-42f11f4cb2d5%40melchiorre.org.

Re: Loading lzma compressed fixtures

[Tim Graham]

Hi Paolo, Please don't ask for code reviews on this mailing list. It just 
adds noise. Patches are reviewed from "Patches needing review" at 
https://dashboard.djangoproject.com/. At this time there are ~30 patches in 
the queue. Requesting your feature to be moved to the front of the review 
queue the weekend before the feature freeze isn't appropriate.

On Saturday, May 9, 2020 at 6:22:13 AM UTC-4, Paolo Melchiorre wrote:
>
> Hi all, 
>
> Working at my latest merged PR [1] in Django I saw in the code the lack 
> of support for lzma compressed fixture for loaddata command so I opened 
> a ticket [2] and a related PR [3]. 
>
> I think is a small PR to accept before Django 3.1 feature freeze but it 
> can be a great improvement in loading big fixtures. 
>
> I would ask someone to review my PR [3]. 
>
> Thanks, 
> Paolo 
>
>
> [1] https://github.com/django/django/pull/12871 
> [2] https://code.djangoproject.com/ticket/31552 
> [3] https://github.com/django/django/pull/12879 
>
> -- 
> https://www.paulox.net 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/070f2da9-bf9c-4798-8cb5-64e3f91723f0%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Aymeric Augustin]

Hello,

This is quite disruptive — says the guy who suggested to remove request.REQUEST 
a few years back — but I think we could go ahead and do it. The names proposed 
by Adam are good.

I read the concerns about  (e.g. for search forms) where 
form data ends up in query_params and not form_data. I'd call this a feature 
:-) Here's why:

- Users who don't know that GET queries mustn't have side effects and who don't 
want to bother will have an incentive to use a POST query to get the data in 
form_data; this is the safe option with regards to CSRF;
- Users who understand the safety model of browsers and who can determine that 
their view isn't vulnerable to CSRF will understand that the form data is in 
query_params, because that's where it is really.

Also, looking at various names between `form_data` and 
`form_data_decoded_from_x_www_form_urlencoded_post_body` (the technically 
correct name), I believe that `form_data` is the best compromise between 
clarity and terseness.

Best regards,

-- 
Aymeric.



> On 5 May 2020, at 23:26, Adam Johnson  wrote:
> 
> request.GET and request.POST are misleadingly named:
> GET contains the URL parameters and is therefore available whatever the 
> request method. This often confuses beginners and “returners” alike.
> POST contains form data on POST requests, but not other kinds of data from 
> POST requests. It can confuse users who are posting JSON or other formats.
> Additionally both names can lead users to think e.g. "if request.GET:" means 
> "if this is a GET request", which is not true.
> 
> I believe the CAPITALIZED naming style was inherited from PHP's global 
> variables $_GET, $_POST, $_FILES etc. ( 
> https://www.php.net/manual/en/reserved.variables.get.php 
>  ). It stands out 
> as unpythonic, since these are instance variables and not module-level 
> constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants 
>  ).
> 
> I therefore propose these renames:
> request.GET -> request.query_params (to match Django Rest Framework - see 
> below)
> request.POST -> request.form_data
> request.FILES -> request.files
> request.COOKIES -> request.cookies
> request.META -> request.meta
> Since these are very core attributes and the change would cause a huge amount 
> of churn, I propose not deprecating the old aliases immediately, but leaving 
> them in with a documentation note that they "may be deprecated." Perhaps they 
> can be like url() or ifequal which came up on the mailing list recently - put 
> through the normal deprecation path after a few releases with such a note.
> 
> Django Rest Framework already aliases GET as request.query_params in its 
> request wrapper: 
> https://www.django-rest-framework.org/api-guide/requests/#query_params 
>  . 
> Therefore the name request.query_params should not be surprising. DRF also 
> provides request.data which combines request.POST and request.FILES, and 
> flexibly parses from different content types, but I'm not sure that's 
> feasible to implement in Django core.
> 
> For reference, other Python web frameworks have more "Pythonic" naming:
> Bottle: request.url_args, request.forms, request.files, request.cookies, 
> request.environ
> Flask: request.args, request.form, request.files, request.cookies, 
> request.environ
> Starlette: request.query_params, request.form(), request.form()[field_name], 
> request.cookies, scope
> One more note for those who might think such core attributes should be left 
> alone: Django 2.2 added request.headers as a way of accessing headers by 
> name. This is convenient as it avoids the need to transform the header to the 
> WSGI environ name. makes the code more readable, and in the process reduces 
> the potential for bugs. I believe this proposal is in the same vein.
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dj

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Florian Apolloner]

On Saturday, May 9, 2020 at 1:41:41 PM UTC+2, Aymeric Augustin wrote:
>
> - Users who don't know that GET queries mustn't have side effects and who 
> don't want to bother will have an incentive to use a POST query to get the 
> data in form_data; this is the safe option with regards to CSRF;
>

This is imo the best argument in this thread and convinces me a little bit 
:D But I still think we should accompany this with documentation that 
explains why GET-powered forms do not show up in form_data. What irks me a 
little bit is that request.GET/POST nicely stood out in code -- ie I could 
find user input handling on a first glance.

As for disruption, can we just alias them for now and drop GET/POST from 
the docs and not immediately start with warnings?

Cheers,
Florian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce0ea3c0-0a73-401e-a2ca-8427b4551f7d%40googlegroups.com.

Re: Loading lzma compressed fixtures

[Paolo Melchiorre]

On 09/05/20 12:39, Tim Graham wrote:

On Saturday, May 9, 2020 at 6:22:13 AM UTC-4, Paolo Melchiorre wrote:

Working at my latest merged PR [1] in Django I saw in the code the lack
of support for lzma compressed fixture for loaddata command so I opened
a ticket [2] and a related PR [3].
I think is a small PR to accept before Django 3.1 feature freeze but it
can be a great improvement in loading big fixtures.
I would ask someone to review my PR [3].
[1] https://github.com/django/django/pull/12871
[2] https://code.djangoproject.com/ticket/31552
[3] https://github.com/django/django/pull/12879
Hi Paolo, Please don't ask for code reviews on this mailing list. It 
just adds noise. Patches are reviewed from "Patches needing review" at 
https://dashboard.djangoproject.com/. At this time there are ~30 patches 
in the queue. Requesting your feature to be moved to the front of 
the review queue the weekend before the feature freeze isn't appropriate.


Hi Tim,

Sorry, I wasn't aware of the dashboard and I definitely didn't want to 
ask my feature to be moved to the front of the review queue.


Next time I won't ask for code reviews on this mailing list.

Thanks,
Paolo
--
https://www.paulox.net

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77a9f90e-d934-b23b-fe71-e3a6d421adba%40melchiorre.org.

Re: Removing url() ?

[Aymeric Augustin]

Hello,

When proposing deprecations that require numerous but simple code changes, 
providing an automated upgrade path could reduce frustrations about "useless 
churn".

Unfortunately, I don't know a great way to do that on Python code. Here are the 
options I'm aware of:

- Writing 2to3 fixers is painful, in my experience 
.
 Also, I don't think that 2to3 will survive the deprecation of lib2to3; removal 
is scheduled for Python 3.12.
- Bowler  seems designed to make it less painful, but is 
also written on top of lib2to3, so not a long term solution.
- codemod  gives up fully automated 
refactoring (which is at odds with Python's dynamic nature) and attempts 
"computer-aided refactoring".
- Most likely IDEs like PyCharm can rename an import throughout a project.

If I had to do something in this area, I'd try codemod, probably.

Of course, it will still be boring to perform the same change across N projects 
for no direct project-level upside, but at least it may require less time and 
less focus.

This is relevant for the thread about renaming request.GET/POST/etc. If we 
proceed with that change, we're bound to have the exact same discussion about 
removing the original names.

Best regards,

-- 
Aymeric.



> On 5 May 2020, at 17:41, Collin Anderson  wrote:
> 
> Hi All,
> 
> Are we _sure_ we want to completely get rid of url()?
> 
> Yesterday, url() was given a RemovedInDjango40Warning [PR]. The removal was 
> approved as part of the new path() syntax back in 2017 [DEP 0201].
> 
> Is this really worth it? It's only a few lines of code to keep backward 
> compatibility, and it seems to me it would take almost no work to maintain 
> that compatibility shim compared to the countless programmer hours needed to 
> upgrade their code, including many unpaid programmers working on open source 
> projects. I'll personally need to do a find/replace for url() to re_path() 
> across my ~20 projects, and update all of the imports. Isn't this useless 
> code churn?
> 
> Yes, there's an advantage to having one and only one way to do it, so I agree 
> we should encourage people to use re_path() instead of url(), but shouldn't 
> we also make it as easy as possible to upgrade django? Is getting rid of 
> url() really worth the cost?
> 
> Yes, the removal is still ~3+ years away, but that's a question of _when_ not 
> _if_.
> 
> If we want, we _could_ deprecate url() without giving it an actual removal 
> date [Compatibility Discussion] and leave the compatibility shim around 
> longer, if not indefinitely.
> 
> Thanks,
> Collin
> 
> 
> [PR] https://github.com/django/django/pull/12855
> 
> [DEP 0201] 
> https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst
> 
> [Compatibility Discussion] 
> https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/236BB3BC-B228-4676-8955-4E302A38197F%40polytechnique.org.

Re: Removing url() ?

[Adam Johnson]

Automated upgrade tooling would be great. Developers end up building their
own anyway.

One more tool we could copy is pyupgrade (
https://pypi.org/project/pyupgrade/ ). It's based upon an extension to
'tokenize' by the author (Anthony Sottile) that allows roundtripping (which
I guess would be useful being merged to the stdlib). But it also looks
possibly painful to work with.

I've tried Bowler and it has a nice interface, allowing git-add-patch
presentation through its idiff() command. But it doesn't have many examples
in its documentation, which made me give up. It's also based on lib2to3,
through a separated copy called fissix.

codemod's README lists Python 2 support only :(

regexes for find/replace, maybe with a sed command, would be the lowest
common denominator. Combined with "git add --patch", then "git checkout ."
that's basically what codemod does (afaiu).

On Sat, 9 May 2020 at 13:32, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> When proposing deprecations that require numerous but simple code changes,
> providing an automated upgrade path could reduce frustrations about
> "useless churn".
>
> Unfortunately, I don't know a great way to do that on Python code. Here
> are the options I'm aware of:
>
> - Writing 2to3 fixers is painful, in my experience
> .
> Also, I don't think that 2to3 will survive the deprecation of lib2to3;
> removal is scheduled for Python 3.12.
> - Bowler  seems designed to make it less painful,
> but is also written on top of lib2to3, so not a long term solution.
> - codemod  gives up fully automated
> refactoring (which is at odds with Python's dynamic nature) and attempts
> "computer-aided refactoring".
> - Most likely IDEs like PyCharm can rename an import throughout a project.
>
> If I had to do something in this area, I'd try codemod, probably.
>
> Of course, it will still be boring to perform the same change across N
> projects for no direct project-level upside, but at least it may require
> less time and less focus.
>
> This is relevant for the thread about renaming request.GET/POST/etc. If we
> proceed with that change, we're bound to have the exact same discussion
> about removing the original names.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 5 May 2020, at 17:41, Collin Anderson  wrote:
>
> Hi All,
>
> Are we _sure_ we want to completely get rid of url()?
>
> Yesterday, url() was given a RemovedInDjango40Warning [PR]. The removal
> was approved as part of the new path() syntax back in 2017 [DEP 0201].
>
> Is this really worth it? It's only a *few lines of code* to keep backward
> compatibility, and it seems to me it would take *almost no work to
> maintain* that compatibility shim compared to the countless programmer
> hours needed to upgrade their code, including many unpaid programmers
> working on open source projects. I'll personally need to do a find/replace
> for url() to re_path() across my ~20 projects, and update all of the
> imports. Isn't this *useless code churn*?
>
> Yes, there's an advantage to having one and only one way to do it, so I
> agree we should encourage people to use re_path() instead of url(), but
> shouldn't we also make it *as easy as possible to upgrade django*? Is
> getting rid of url() really worth the cost?
>
> Yes, the removal is still ~3+ years away, but that's a question of _when_
> not _if_.
>
> If we want, we _could_ deprecate url() without giving it an actual removal
> date [Compatibility Discussion] and leave the compatibility shim around
> longer, if not indefinitely.
>
> Thanks,
> Collin
>
>
> [PR] https://github.com/django/django/pull/12855
>
> [DEP 0201]
> https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst
>
> [Compatibility Discussion]
> https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com
> 
> .
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/236BB3BC-B228-4676-8955-4E302A38197F%40polytechnique.org
> 

Re: Technical Board statement on type hints for Django

[Aymeric Augustin]

Sorry for the late answer, I didn't have time to read this mailing list for the 
last month :-( Here's my position on the matter.

Adding type annotations only makes sense if a type checker checks them. 
Otherwise, they're unlikely to be correct and usable, so it would be 
counterproductive to add them. Unfortunately, I don't think we have a good 
enough type checker yet.

I'm having a rough experience maintaining type checking with mypy in websockets 
, a library that is very much smaller 
and simpler than Django. (Some problems are related to async, which isn't a 
concern for Django, but that doesn't explain everything.)

* Besides adding the type annotations, type checking required many other code 
changes. Importing types in modules that need them created circular 
dependencies. Fixing these import loops required moving imports to the bottom 
(ugh), splitting code in small modules (meh), or always importing modules 
rather than objects inside modules (perhaps a good practice, but changing this 
throughout a project creates a lot of noise). Also, import loops tend to 
reappear when implementing new features or refactoring.

* It's an uphill struggle to keep up with subtle changes of behavior in mypy — 
which is still 0.x software. I also encountered regressions that required 
pinning to an old version. Supporting more than one mypy version seems out of 
reach. I'm very pessimistic about supporting more than one type checker.

* I don't remember mypy catching interesting bugs. I'm keeping it only because 
I'm failing to deal with the sunk cost logical fallacy :-( Overall, adding type 
annotation to websockets has decreased my ability and willingness to maintain 
it. I believe it increased the barrier to entry for other contributors as well.

So, I think the ecosystem needs to stabilize a lot before Django can adopt 
static typing, even just as a best practice for new code. Comments like this 
one  make me 
uncomfortable about living that close to the edge.

Also, given that static typing was bolted on Python very late in its history 
and that there's a strong tradition of relying on duck typing, I'm not yet 
convinced static typing will ever be widely accepted as a best practice.

tl;dr I'm recommending to wait and see.

For the record, I'm a huge fan of good type systems. My second programming 
language after Basic was Caml , which has fantastic type 
inference: you never declare types but everything is strongly statically typed 
at compile time. I loved it. In contrast, having to declare types manually to 
get passable type checking isn't good enough for me.

Finally, I have to say that I was impressed by the effort that Maksim (author 
of the DEP), along with others, put into making mypy work with the more dynamic 
parts of Django. For example, typing of QuerySet arguments is impressive: 
https://github.com/django/deps/pull/65/files#diff-afab5a339bc83e08032ffb9446fb5103R185
 
.
 The documentation mentions a list of things that work, which suggests that 
edge cases not mentioned in the list may not work, so it isn't clear to me if 
it's possible to build a 100% correct solution with this approach. Still, it's 
impressive!

Best regards,

-- 
Aymeric.



> On 17 Apr 2020, at 14:19, charettes  wrote:
> 
> Thanks for sharing your answer publicly Adam and Markus. Here are the points 
> I brought up in the discussion
> 
> From my limited experience with type annotation on a large monolithic code 
> base that was ported from Python 2 to 3 even gradual typing has been a lot of 
> trouble for the few benefits it brought us.
> 
> This partially explains why I had reservations about the benefits of the 
> proposal .
> 
> I also think that it's a bit too early to bundle type annotations in the core 
> repository and I'd favour an approach where we make adjustments to the source 
> to add entry points allowing third parties to implement and maintains such 
> type annotations. That's the approach we've taken in the past when a new 
> feature is suggested for inclusion in core; we add missing entry points for 
> the feature to be implemented externally instead. This should allow different 
> tools to compete organically in the ecosystem without having to choose the 
> best candidate right now.
> 
> I'm -0 on allowing stdlib type annotations in the mean time since I feels 
> like it would open a can of worms that we want to keep sealed for now. What 
> if a function accepts/return a non-stdlib type (or an Union of a stdlib and 
> non-stdlib), do we type annotate it? What if we have to change this function 
> to a Union[non-stdlib-type, stdlib-type], should we completely drop the type 
> annotation on that function?
> 
> Simon
> 
> Le vendredi 17 avril 2

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Tim Allen]

I'm tentatively +1 on this change... but...

While it may be a straightforward operation to do a case sensitive search 
and replace in most code bases, it is not trivial to do so on the rest of 
the web. If we're going to do this, we must realize that this will 
invalidate thousands of examples, tutorials, and answers in communities 
such as Stack Overflow, the Django Forum, the Django Girls Tutorial, and 
the archive of this Google Group. It has been a few years now since Django 
2.0, and I still find myself frequently helping junior developers amend 
their PRs to move to `path` and `re_path` instead of `url`, which they 
copypasta'd from somewhere. I was also for that change, but as a community, 
we need to be cognizant of the fact that as its ambassadors, we are going 
to have a fair amount of work to do to properly spread the word about a 
change like this.

There are many possible responses to why that shouldn't be happening in a 
perfect world, unfortunately, we have to exist in this reality! (I'm hard 
at work at the unreality PR for Django 5.0.)

So let's make sure we consider the full impact of this change before we do 
it. I have some pet peeves about Django naming choices, but where do we 
stop? Two examples:

* createsuperuser -> create_super_user, queryset -> query_set,  for 
readability and to be more Pythonic
* HttpResponse should be HTTPResponse, like DjangoJSONEncoder, for example. 
(From PEP-8: "Note: When using acronyms in CapWords, capitalize all the 
letters of the acronym. Thus HTTPServerError is better than 
HttpServerError.")

Something to consider for the future about when the churn is worth it, and 
when it isn't. Thanks, y'all.

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5022af59-4280-4dca-a33e-d7ec79bc131b%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Tobias McNulty]

Tim your point is well made. I'm left  with the feeling that an imperfect
convention is really not so bad, and possibly not worth the huge number of
global developer hours it would cost to effect such a change.

Plus (I make this argument mostly in jest), the new names, because they are
more Pythonic, probably would not stick out so well / not be as easy to
search for. :D

Tobias


On Sat, May 9, 2020, 12:41 PM Tim Allen  wrote:

> I'm tentatively +1 on this change... but...
>
> While it may be a straightforward operation to do a case sensitive search
> and replace in most code bases, it is not trivial to do so on the rest of
> the web. If we're going to do this, we must realize that this will
> invalidate thousands of examples, tutorials, and answers in communities
> such as Stack Overflow, the Django Forum, the Django Girls Tutorial, and
> the archive of this Google Group. It has been a few years now since Django
> 2.0, and I still find myself frequently helping junior developers amend
> their PRs to move to `path` and `re_path` instead of `url`, which they
> copypasta'd from somewhere. I was also for that change, but as a community,
> we need to be cognizant of the fact that as its ambassadors, we are going
> to have a fair amount of work to do to properly spread the word about a
> change like this.
>
> There are many possible responses to why that shouldn't be happening in a
> perfect world, unfortunately, we have to exist in this reality! (I'm hard
> at work at the unreality PR for Django 5.0.)
>
> So let's make sure we consider the full impact of this change before we do
> it. I have some pet peeves about Django naming choices, but where do we
> stop? Two examples:
>
> * createsuperuser -> create_super_user, queryset -> query_set,  for
> readability and to be more Pythonic
> * HttpResponse should be HTTPResponse, like DjangoJSONEncoder, for
> example. (From PEP-8: "Note: When using acronyms in CapWords, capitalize
> all the letters of the acronym. Thus HTTPServerError is better than
> HttpServerError.")
>
> Something to consider for the future about when the churn is worth it, and
> when it isn't. Thanks, y'all.
>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5022af59-4280-4dca-a33e-d7ec79bc131b%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKQwPiaS2UtCnaTQ-Q0HL7ZAP1iQyWDraECEiDKgj1gnsA%40mail.gmail.com.

Re: Management of static assets

[Aymeric Augustin]

Thanks David for investigating the topic thoroughly! I wasn't expecting all 
that when I filed a one-line ticket six years ago :-) So, here's a bunch of 
opinions.


Before I start, I'd like to quote the intro to the Media class 
:

> Rendering an attractive and easy-to-use Web form requires more than just HTML 
> - it also requires CSS stylesheets, and if you want to use fancy « Web2.0 » 
> widgets, you may also need to include some JavaScript on each page. The exact 
> combination of CSS and JavaScript that is required for any given page will 
> depend upon the widgets that are in use on that page.


That was the reasonable thing to do before single-page apps, asset pipelines, 
bundlers and code splitting. It's still a fairly reasonable thing to do on a 
website that relies on good old HTML forms but would benefit from "fancy « 
Web2.0 » widgets".


1. Django shouldn't do anything (besides what django.contrib.staticfiles 
already does) for projects that use webpack (or any other bundler)

The correct approach with a bundler is to bundle all JavaScript code and, if 
needed, to optimize with code splitting. Attempting to include only what's 
needed on each page, like Media does, will usually be counterproductive, 
because it will general different bundle for different pages and defeat caching 
by the browser.

Then I know two techniques for integrating the frontend code with Django:

- the single page app 

 (website and API on separate domains) — this is clearly out of scope of this 
discussion as Django only provides an API in this scenario
- what I call the hybrid app 

 (website and API on the same domain) — here django.contrib.staticfiles helps; 
it comes after the JavaScript bundler in the deployment pipeline (and I prefer 
plain django.contrib.staticfiles over django-webpack-loader, but that's another 
story)

(NB: while the blog posts I just linked to focus on create-react-app, the 
concepts apply to any modern JavaScript toolchain.)

Regardless, Django already provides more than we need. For example, both 
webpack and django.contrib.staticfiles add hashes to file names to ensure cache 
invalidation.

So my answer to questions 3, 4 and 5 is "no, except maybe documentation".

Now, let's leave this brave new world and remember the jQuery era.


2. Media makes sense

Although pluggable apps are fantastic, the concept doesn't work well for 
templates, which is where  and