Re: Removal of USE_L10N setting

[René Fleschenberg]

Hi Claude,

> I understand this concern. I wonder if that could be solved separately,
> for example by:
>  - returning int subclasses from AutoField's to_python (a bit like
> str/SafeString for handling escaping)
>  - not localizing those integers, unless use_l10n is forced (True)
> Does this look like a plan (even without touching USE_L10N)?


Sounds good to me!

-- 
René

-- 
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/4a346495-ded1-5eea-6265-ab5c0378fde9%40fleschenberg.net.

Re: Removal of USE_L10N setting

[René Fleschenberg]

Hi,

On 6/11/21 6:50 PM, Claude Paroz wrote:
> Is there a possible deprecation path?

Maybe add a system check that warns if the setting is still present?

-- 
René

-- 
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/fad2c246-f32f-6f97-d459-659b724d5abf%40fleschenberg.net.

Re: Removal of USE_L10N setting

[René Fleschenberg]

Hi,

On 6/11/21 6:50 PM, Claude Paroz wrote:
> As usual, the main drawback is backwards compatibility. The possibly
> affected projects are those having USE_L10N = False, along with multiple
> LANGUAGES.
> 
> Is this a good idea?
> I would also like to get opinions here about the compatibility issues.
> Are they acceptable?
> Is there a possible deprecation path?

I have run into bugs because template authors forgot to unlocalize
values, in particular database IDs. These bugs often go unnoticed for
quite a while because they only show up once you reach 1000 database
rows. Forgetting to localize a value would typically be a much more
obvious bug.

So far, I have always fixed these issues by adding the unlocalize
filter, though I did ponder using USE_L10N = False in the past. I don't
know how many projects there are in the wild that go with USE_L10N = False.

Personally, I believe removing the setting and **not** localizing values
unless explicitly requested would be the best option in the long run.
But I guess that would create much bigger compatibility issues.

Overall, I'm +0 on this.

-- 
René

-- 
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/a3b281a1-a7c0-73b8-6d7d-6e89c7d8e50a%40fleschenberg.net.

Re: Do people actually squash migrations?

[René Fleschenberg]

Hi,

I agree that it would be good to extend the docs and to describe how to
reset a project's migrations. Some prior art on this:

https://geekchick77.dreamwidth.org/5560.html

https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html


Regards,
René

-- 
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/9d103a6d-1301-1a37-ef35-29b6f1521f51%40fleschenberg.net.

Re: Replace the default django test runner to a more robust testing framework (like pytest)

[René Fleschenberg]

Hi,

On 15.12.20 15:48, Tobias Bengfort wrote:
My issue is mostly that pytest uses a lot of magic that is hard to 
debug, e.g. the overwritten assert statement or implicit injection of 
fixtures. Most pro arguments seem to depend on personal taste.


It should be noted that you can use pytest / pytest-django as a test 
runner without having to use any other pytest features (it can run 
unittest-style tests, you don't have to rewrite them). I do think it has 
some features in the test runner. For example, the -k command line 
option to quickly select tests, or --last-failed to rerun failed tests.


However, since pytest-django exists and has been working flawlessly for 
me for several years, I am not sure how much benefit there would be in 
having this in Django itself.


Regards,
René

--
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/3810f1f8-fc22-6fea-51d1-5bfa1b72523f%40fleschenberg.net.

Re: Should django-admin allow specifying hidden directories for --template?

[René Fleschenberg]

Hi,

On 01.10.20 15:56, laym...@gmail.com wrote:
Thanks for the feedback! From my observations, Django does not ignore 
hidden /files/,
it only ignores hidden /directories/. So, the files that you listed 
should work fine.


Ah, my bad, sorry.

As for the built-in exclusion list, I'm not sure if we should add that. 
I think ignoring .git
by default is fine, but we shouldn't assume that people would like to 
ignore .coverage.


Hmmm, you mean because other tools besides 
https://pypi.org/project/coverage/ might use that path? I guess that 
could happen, yup.


Regarding exclusion vs inclusion... I'm not sure what the best option 
is, though! :)


I think I prefer explicit exclusion by the user (except for obvious 
cases like .git and __pycache__) because it's less surprising.


René

--
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/da363f4b-740d-0300-2c73-31f6ba3b7ac9%40fleschenberg.net.

Re: Should django-admin allow specifying hidden directories for --template?

[René Fleschenberg]

Hi,

I can see several use-cases for hidden files / directories in a project 
template. Here are some examples from one of my current projects:


.coveragerc
.editorconfig
.flake8
.gitignore
.gitlab-ci.yml
.isort.cfg

Instead of introducing a command line option to explicitly include 
things, can we replace the current behavior with a built-in exclusion 
list? And maybe an --exclude option to exclude additional things?


Candidates for the exclusion list that come to my mind:

__pycache__
.git
.coverage

Regards,
René

--
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/904d1155-edf9-c7f2-23b9-59eaf6f82240%40fleschenberg.net.

Re: Django default input validation accepts special caracters

[René Fleschenberg]

Hi,

But when you are making a governmental website for example: you need 
actual identity.


Django makes it possible (I'd even say easy) to setup your forms / 
models to enforce stricter requirements if you have to. We don't have to 
treat these cases as the default. Backwards compatibility is the bigger 
concern here.


Regards,
René

--
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/19bea9a3-2006-8120-4657-63ff0116b5e8%40fleschenberg.net.

Re: Cache framework

[René Fleschenberg]

Hi,

On 8/18/20 3:33 PM, Carlton Gibson wrote:
> I think we SHOULD bring a redis cache backend into core. 
Would this also mean supporting Redis-specific APIs? I'm thinking of
listing keys in particular. Would Django then throw an exception on
backends that don't support this? Or would the built-in cache backend
just not expose those APIs?

-- 
René Fleschenberg

-- 
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/4d2520cd-a693-f1a6-b493-a4d8fd8692d3%40fleschenberg.net.

Re: queryset.values() / GROUP BY

[René Fleschenberg]

Hi Shai,

thanks! I need to look a bit deeper into this I guess.

Just for completeness, I am looking at this code in one of my projects:

```
def get_all_colors(self, queryset):
color_ids = queryset.order_by('color').values_list('color', 
flat=True).distinct()
found_colors = 
Color.objects.filter(id__in=color_ids).prefetch_related('translations')
result = [c.safe_translation_getter("name", any_language=True) for 
c in found_colors]

```

color is a ForeignKey. safe_translation_getter() is from django-parler 
and needs an actual model instance.


I was wondering if I can get rid of the additional 
Color.objects.filter() query.


But I guess this is not such a common use-case and belongs on 
django-users anyway.


Thanks for the clarification!

Regards,
René


On 21.07.20 20:52, Shai Berger wrote:

Hi René,

On Tue, 21 Jul 2020 18:46:12 +0200
René Fleschenberg  wrote:


https://github.com/kako-nawao/django-group-by



It doesn't actually aggregate, so the name "group-by" seems
unwarranted. What it does, as the README explains, is replace "values"
by something which does two things:

- Sets the seclected fields as attributes on the object returned,
   rather than as dict values
- Where the selected field is a FK, follows the relationship to get the
   object


Is there a deeper reason why this functionality is not available in
Django core?


If I'm not mistaken, only() provides this functionality, with the
difference that if you then try to access an unselected attribute on the
object, with only() it is fetched, while with this "group_by()" you get
an AttributeError.

(django-group-by has other limitations -- e.g. it is designed to
handle "rel__field" but not "rel1__rel2__field")

Did I miss anything important?



--
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/c4040127-573a-57cb-7005-59a7bbf87d84%40fleschenberg.net.

queryset.values() / GROUP BY

[René Fleschenberg]

Hi,

on IRC, someone hinted me at 
https://github.com/kako-nawao/django-group-by today.


Is there a deeper reason why this functionality is not available in 
Django core, or is it just that nobody got around to implementing it 
yet? To me, it seems like something that would be nice to have without 
having to rely on a third-party package.


Any thoughts?

Regards,
René

--
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/0cdf647e-295f-6948-abd0-696cb9859efe%40fleschenberg.net.

Re: Should the docs suggest namespace packages?

[René Fleschenberg]

Hi,

On 7/19/20 10:25 PM, Tim Graham wrote:
> Another commenter remarked, "We had a similar issue with test discovery.
> One of our developers read an article that __init__.py files are not
> required on Python3 and started removing them. Everything seemingly
> worked but some tests were not discovered and did not run in CI (which
> made it difficult to spot). I think Django should not required them if
> technically possible or at least it should be made clear in the
> documentation (sorry if I overlooked it)."
> 
> Supporting namespace packages without a real use case seems contrary to
> the consensus in this thread (which I see as not promoting implicit
> namespace packages). Based on that consensus, my inclination wouldn't be
> to try to make Django work with as few __init__.py files as possible.
> What do you think?

I agree. The situation of "One of our developers read an article that
__init__.py files are not required on Python3" is exactly the one we
should act against, as far as we can. This is a common misunderstanding
that we should try to clear up, not promote.

The person you quoted gives an example of why this is not purely
academical. Maybe it's debatable whether Python should behave
differently, but that's not something that Django can fix.

I am in favour of failing early and loudly here. IMHO Django should
ignore migration packages without an __init__.py file, maybe with a
warning, or maybe even with an error.

-- 
René Fleschenberg

-- 
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/50ae4a01-bb94-4581-ba2f-ed2c7fd0b003%40fleschenberg.net.

Re: Making startproject's settings more 12-factor-y

[René Fleschenberg]

Hi,

On 6/26/20 12:11 PM, René Fleschenberg wrote:
> geared towards development (random default value for SECRET_KEY, DEBUG =
> False).

I meant DEBUG = True here, of course :)

-- 
René Fleschenberg

-- 
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/38989a0b-6d61-9317-40f3-588a2bd1c359%40fleschenberg.net.

Re: Making startproject's settings more 12-factor-y

[René Fleschenberg]

Hi Flo,

> And there are plenty more things to consider; for instance I do not
> agree that it makes sense to have "SECRET_KEY" default to a value when
> missing in the env. It is way to easy to type "SECRT_KEY" and never
> realize that. So if "SECRET_KEY" is taken from the environment it should
> fail loudly if it is not present. "DEBUG" is in a similar category there
> but could default to False to be safe.

There is a trade-off between security and development convenience here.
At the moment, the settings generated by manage.py startproject are
geared towards development (random default value for SECRET_KEY, DEBUG =
False). Personally, I like to keep that convenience, so I do

SECRET_KEY = os.environ.get(SECRET_KEY, original_default_value)

There is also manage.py check --deploy. This catches DEBUG = True, but
not SECRET_KEY. Would it be a good idea to prefix the default SECRET_KEY
with something like "insecure-" and check for that in manage.py check
--deploy?

> I personally rather have no solution in Django itself before forcing a
> half-baked one down everyone. Also please note that the bar to add this
> to Django is very high since it can (at least for things like
> django-environ) easily live outside of Django with no realy downside.
+1

-- 
René Fleschenberg

-- 
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/e10f9b32-41af-5cd1-a55d-8b8a9adf4f59%40fleschenberg.net.

Re: Proposal - Warn user when creating or applying a delete migration?

[René Fleschenberg]

Hi,

During makemigrations, on the other hand, I don't see anything wrong 
with formatted text or +/-, but I might go a step further. 


This sounds like a good idea to me. It would break cases where 
makemigrations is run non-interactively, which might be a good thing. 
It's a common mistake to run makemigrations && migrate on deployment 
instead of committing the migrations to version control.


Regards,
René

--
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/c43e301d-5bf8-3ff5-34c6-fd199fb09682%40fleschenberg.net.

Re: The blacklist / master issue

[René Fleschenberg]

Hi,

just my 2 cents:

While I am generally critical of changing language to achieve social
progress, I see no harm in using "main", "develop" or something like
that instead of "master". There might be a tool or two out there that
treat "master" specially, but I can't think of anything that would
directly affect Django. If Github is going to settle for "main", it will
likely become the new convention, so maybe Django should pick that one?

allow_list / deny_list is a similar case. I see no advantage in keeping
the current names. To me, allow_list / deny_list is at least as clear as
white_list / black_list.

When Django directly references externally defined technical terms (e.g.
underlying APIs), I think more consideration is needed. For RFC 5782, I
think that is not the case.

Regards,
René

-- 
René Fleschenberg

-- 
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/7d0f24b3-e042-0964-6be0-6689fc930af1%40fleschenberg.net.

Re: Proposal - Warn user when creating or applying a delete migration?

[René Fleschenberg]

Hi,

>  3. Output a yes/no input prompt asking if the user has made a data
> migration or is aware and acknowledges the risk

Migrations are often applied non-interactively during some kind of
automated deployment step. So this behaviour would have to be somehow
optional. Either it has to detect if it's being run interactively, or we
would have to add a command line switch or environment variable. In that
case there would be the question what the default should be here.
Defaulting to the prompt would be backwards-incompatible.

-- 
René Fleschenberg

-- 
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/bde47e6c-98d2-2b37-ec87-9c9c0c3b4dd3%40fleschenberg.net.

Re: ./manage.py settings

[René Fleschenberg]

Hi,

Just a thought that came to my mind: It would be useful to have a
command that dumps the run-time settings, but automatically replaces
secrets with dummy values.

I think this should not be too hard to do for Django's own secret
settings, and maybe it can also be done for some known common third
party settings (AWS_SECRET_ACCESS_KEY, for example).

Even better would be to have a standardized way of marking settings as
secret, though I am not sure if this is feasible.

Regards,
René

On 6/12/20 5:09 AM, '1337 Shadow Hacker' via Django developers
(Contributions to Django itself) wrote:
> Hi all,
> 
> So, just on #django IRC channel there was a user trying to help another
> one, asking for some settings through ./manage.py shell etc ... A
> discussion that went kind of like "Print out your settings" "How would I
> print, I tried that, I'm in settings.py" "With ... print()" "but in the
> shell, __file__ is not defined" and so on, and 20 minutes later the user
> couldn't print his settings and left.
> 
> TBH I'm pretty fine because the users I support are on projects where I
> added djcli to the requirements, so I can always ask the to do the djcli
> setting command to print out a setting. It's very useful useful to me, I
> think Django should a command to dump runtime settings because that
> should make the life easier of Django users trying to support newbies in
> their own projects, where they don't have installed a custom command,
> it's pretty cheap to make and maintain and should save quite some
> frustration from both sides of the story.
> 
> What do you think ?
> 
> 
> -- 
> 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
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/X2HkH0yasxu2XVxBuVkbTfdSHctL7y3pW9seQ8CHFcVOpmsiyN80JlDYH2g5F6IfPvEdN4zyG6vuxj2HEMJaXUSErMUM5IT70iLvkxsrc7U%3D%40protonmail.com
> <https://groups.google.com/d/msgid/django-developers/X2HkH0yasxu2XVxBuVkbTfdSHctL7y3pW9seQ8CHFcVOpmsiyN80JlDYH2g5F6IfPvEdN4zyG6vuxj2HEMJaXUSErMUM5IT70iLvkxsrc7U%3D%40protonmail.com?utm_medium=email&utm_source=footer>.

-- 
René Fleschenberg

Rosastrasse 53, 45130 Essen, Germany
Phone: +49 1577 170 7363
https://fleschenberg.net
E-mail: r...@fleschenberg.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/501b33d3-9191-69a0-01dd-5c875f048073%40fleschenberg.net.

Re: Should the docs suggest namespace packages?

[René Fleschenberg]

On Github, Tim pointed out that with
https://github.com/django/django/commit/ccc25bfe4f0964a00df3af6f91c2d9e20159a0c2,
various __init__.py files in Django's own code were removed.

I tend to say it would be good to revert that change. Or we could update
the docs only, since they serve much more directly as an example for
user code.

-- 
René Fleschenberg

-- 
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/5d689d5c-01ab-d017-249c-a53a6d9b1f87%40fleschenberg.net.

Should the docs suggest namespace packages?

[René Fleschenberg]

Hi,

https://github.com/django/django/pull/12939

My opinion on this is not particularly strong, but it seems odd to me
that we tell users to create namespace packages, without any
explanation. What do you think?

-- 
René Fleschenberg

-- 
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/a604b2d5-23a5-67da-b8c4-f50e1d434fb7%40fleschenberg.net.

Re: Deadlock bug in logging? Reproducible case

[René Fleschenberg]

Hi,

On 4/23/20 12:20 PM, Adam Johnson wrote:
> What version of Python René?

I tested with 3.6.7. I can test with other versions, if that helps.

Regards,
René



-- 
René Fleschenberg

-- 
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/238fdf4b-fb01-f2b8-bbc1-ef065c0ebd63%40fleschenberg.net.

Re: Deadlock bug in logging? Reproducible case

[René Fleschenberg]

Hi,

On 4/23/20 9:40 AM, Adam Johnson wrote:
> Brian - You didn't describe the exact symptoms you're seeing. "Deadlock"
> has a particular technical meaning around multiple processes requesting
> locks mutually off each other, and normally ends in one process being
> terminated. But I presume you're experiencing more of a "standstill" and
> future requests no longer work?

I was able to reproduce this. It leads to a standstill, further requests
are not getting processed. I can reproduce it when logging to the
console, so I don't think disk I/O is the problem. It might still be a
problem in the Python stdlib, of course.

-- 
René

-- 
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/1b14cc08-4abf-9a97-8e02-a16931c0bf28%40fleschenberg.net.

Re: Deprecating logout via GET

[René Fleschenberg]

Hi,

On 04.03.20 12:13, Sam Willis wrote:

Why not have the logout link take the user to a page asking them to confirm the 
logout, and have it as a POSTed form button from there?

That adds a helpful confirmation page, removes the difficulties of styling a 
button as a link constantly (or changing the header design to a button).

One downside would be the change in behaviour, people will be used to the 
logout link immediately logging them out and so may not read the next page...


Personally I am fine with an intermediate page or without one.

It would just be nice to reach some decision on this so we can then move 
forward with https://github.com/django/django/pull/12505, or file 
another PR that introduces the intermediate page.


I agree with Aymeric that some accessibility testing on this would be 
good, however.


Regards,
René

--
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/73911665-10b8-b487-700d-e29372b05956%40fleschenberg.net.

Re: Deprecating logout via GET

[René Fleschenberg]

Hi,

On 3/2/20 9:34 PM, Tim Chase wrote:
> On 2020-03-02 18:35, Anna Sidwell wrote:
>> Is there any particular reason why it shouldn't look like a button
>> instead of a link?
> 
> The concern isn't how it looks (with CSS you can make a button look
> like a link, or make a link look like a button).
> 
> An  does the logout action via a GET (and is the problem
> at hand) while a / does the logout action via the
> form method and can be either a GET (which would still a problem) or a
> POST (the goal).
I think the question was if we want to retain the current link-like
appearance on changing this to  / POST ;)

The reason I see for doing so is that it blends in with the other
user-tools links (view site, change password). But I think Anna raises a
good point. If someone can come up with a nice button-like design, why
not? Maybe a button-like design would actually be a better UI here?

-- 
René Fleschenberg

-- 
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/37bdb86c-fc9a-a4e8-0fa6-e82424805a03%40fleschenberg.net.

Re: Deprecating logout via GET

[René Fleschenberg]

Hi,

On 2/29/20 5:01 PM, Florian Apolloner wrote:
> I found an example on stackoverflow on how we could do this in the admin
> without JS (with a bit of styling): https://stackoverflow.com/a/33880971
> -- I personally would prefer it if we would not need javascript for a
> fundamental functionality like this.

I found the same example and based
https://github.com/django/django/pull/12505 on it :) If anyone has some
time to review / test it, that would be great.

-- 
René Fleschenberg

-- 
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/4912624f-5576-a009-6cfa-54af05d15a9f%40fleschenberg.net.

Re: Deprecating logout via GET

[René Fleschenberg]

Hi,

On 2/28/20 5:04 PM, 'Maher, Brian' via Django developers (Contributions
to Django itself) wrote:
> Are any current browsers dumb enough to prefetch logout links these
> days? I would assume that most prefetch algorithms are smart enough to
> not pre-fetch these.

We not only have to consider browsers, but also current and future
frontend frameworks.

I don't know how often people run into this in practice, but yesterday
someone mentioned on IRC that they got caught by this while
experimenting with some JS preloading. I also vaguely remember having
seen reports on similar issues by others over the years (maybe not all
of them for Django, though).

You can also find tickets like
https://bugs.chromium.org/p/chromium/issues/detail?id=86175. To sum up,
I don't think this is a purely academical problem.

> I just don’t see the benefit, in return for breaking practically every
> logout button on every installation of Django around.

If I write a logout button myself, I use POST nowadays. The logout view
has supported POST for a while now. But I don't know how widespread POST
vs GET is for this in user code overall.

I don't think this is a particularly painful adjustment to make on a
major version upgrade. Maybe we can provide a specific example in the
release notes. IMO, in the end it is better to make users go through
this at some point in time than to maintain the undesired behavior forever.

-- 
René Fleschenberg

-- 
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/55c09ec2-8d40-aaf6-a190-a0925b6c7299%40fleschenberg.net.

Re: Deprecating logout via GET

[René Fleschenberg]

Hi,

On 2/28/20 12:12 AM, Adam Johnson wrote:
>  > The reason this was not changed yet is backwards compatibility.
> 
> Do you have any mailing list / ticket links as reference?

Sorry, I forgot to link them here. The main ticket seems to be
https://code.djangoproject.com/ticket/15619.

Mailing list dicussions are at
https://groups.google.com/forum/#!topic/django-developers/MmFzCq8oB5I/discussion
and
https://groups.google.com/forum/#!topic/django-developers/ax95u_f82D4/discussion.

-- 
René Fleschenberg

-- 
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/f6c73570-5276-d789-db00-c162457ac5bb%40fleschenberg.net.

Deprecating logout via GET

[René Fleschenberg]

Hi everyone,

there seems to be consensus that logging the client out on GET requests
to the logout view is not great. Clients may try to prefetch links (this
came up on IRC today). Attackers might annoy users by logging them out
with embedded links to the logout URL.

The reason this was not changed yet is backwards compatibility.

I'd like to propose deprecating logging out via GET with the usual
deprecation cycle, so that we have the possibility to stop supporting it
in Django 4.0.

In my opinion, this is a fairly easy change for Django users to make
upon a Django update. Some changes to Django itself will also have to be
made (the admin templates), but I think it should be possible to do
those before the 4.0 release. And even if that doesn't happen, emitting
a DeprecationWarning in 3.1+ wouldn't harm, right?

What do you think?

I went ahead and created a PR for this:
https://github.com/django/django/pull/12504

-- 
René Fleschenberg

-- 
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/9baf0189-fc7a-80a0-6543-559c2b2b186a%40fleschenberg.net.

Re: Allowing model field choices to receive a list of strings instead of a list of string tuples

[René Fleschenberg]

Hi

> Could we allow lists to be passed to choices ?
> `|choices=['potato', 'carrot', 'turnip']|`

I do not think that this justifies a change in Django. You can do this,
if you like:


def to_choices(values):
return [(x, x) for x in values]

myfield = CharField(
choices=to_choices([
'potato',
'carrot',
'turnip',
])
)


A list of strings might be less cognitive load for those developers who
never need to change (or translate!) the display names, but for all
others, it will be more confusing.

-- 
René Fleschenberg

-- 
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/331699be-426a-3ad9-5422-ee21f41bf98b%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Why does ModelForm do validation and not Model

[René Fleschenberg]

Hi

On 4/18/19 2:07 PM, Václav Řehák wrote:
>  As a veteran Django user, I am quite used to it but as I work on
> financial project (with strong requirements on data consistency) with a
> team of senior developers kind of new to Django I face a lot of
> confusion about why does Django let us save invalid data (actually last
> week I spent almost 3 days on fixes caused forgotten calls to full_clean
> and on data migration to clean up the mess). If it was possible, e.g. in
> settings, to force model validation in save(), it would help us a lot.
You can make an abstract model with an overriden save() that calls
full_clean() and inherit all your models from it. However, remember that
this does not cover all database writes. For example, update() on a
queryset does not call save(). For this reason, I don't think it is a
good idea. It just gives developers a false sense of security. Instead,
make sure to validate all input at the application boundary (e.g. using
forms).

If data integrity is really important, also consider using
database-level constraints. This can be done using raw SQL from a
migration. In Django 2.2, there also is
https://docs.djangoproject.com/en/2.2/ref/models/constraints/.


-- 
René Fleschenberg

-- 
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/8ce3915a-de41-8fee-c36e-078d003b1677%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[René Fleschenberg]

Hi Ned.

> Try the latest black.  A multi-line lists with comments on each line is
> not converted to a one-line list.  The lined-up indentation of the
> comments is lost :(, but it's still multi-line.

Hmmm, I tried commit cea13f4 (current master at the time of this writing).

It turned

l = [
1,  # one
2,  # two
3,  # three
]

into

l = [1, 2, 3]  # one  # two  # three

Maybe in your case the line limit kicked in and prevented the reformatting?

> This is one of my concerns: Black is still beta, and is still adjusting
> the way it formats in small ways.  So a boil-the-ocean formatting of the
> code may not be the last time the code will change to suit black.

I agree.

-- 
René

-- 
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/2137d5e8-80fd-eecc-9128-8e0f31d606d7%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[René Fleschenberg]

Hi

> HMS = "%H:%M:%S"  # 14:30:59
> HMSF = ".." 
> HM = ".."
> TIME_INPUT_FORMATS  = [HMS, HMSF, HM]

Just my two cents: This particular rule is the main reason why I
personally have not adopted black yet. I really find the
one-item-per-line style *much* more readable in many cases.

In natural-language writing, there are occasions where you use "foo,
bar, baz" and other occasions where you use

- foo
- bar
- baz

IMO, both variants have their place in Python code, too. I'd like to see
a black variant which allows to leave this decision to a human.

-- 
René

-- 
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/1a9e62ac-8cdc-6660-2587-204230ec8dbf%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[René Fleschenberg]

Hi

> Also related: UserCreationForm by default allows usernames that differ
> only by case
> https://code.djangoproject.com/ticket/25617

I would like to mention CITextField / CIEmailField here. It solves this
problem nicely, in my experience.

However, it is only available on Postgres, and it requires a database
extension that in turn requires superuser access to the database to be
installed.

Do you think it would be realistically possible to have a CITextField
that uses Postgres citext when available and falls back to Python in
other cases?

-- 
René Fleschenberg

-- 
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/f91b347e-7fc9-f559-c5d4-e2c1124aadfd%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[René Fleschenberg]

Hi.

On 3/18/19 12:26 PM, Mat Gadd wrote:
> Weirdly, it appears that Gmail isn't inserting click tracking for the
> plain password reset link, but when I use my own URL shortener, I can
> also see the google.com  redirect in play. It may
> just be dev tools behaving strangely, or perhaps Google have tried to
> avoid adding their tracker for password reset links. Who knows!

I did not take the time to analyze this as thoroughly as I should have,
but from a cursory look, it seemed to me that Gmail rewrites the links
using Javascript, and only when you click on them. Could that explain
why your observations?

-- 
René

-- 
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/0e45692d-1974-25ff-c938-f4770f8ee786%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[René Fleschenberg]

Hey,

I ran into this today. I am reusing the password reset views for user
signup, so it affects me quite heavily :)

No idea if it is going to be of any use, but I sent a report on
https://www.apple.com/feedback/safari.html with links to your ticket and
this discussion.

I will try to get my hands on a Mac for further debugging soon.

Cheers,
René

-- 
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/ad17bd8e-417b-4e6c-2ddc-322b3e59d0f6%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Can we make HTTP 308 the default for CommonMiddleware / APPEND_SLASH?

[René Fleschenberg]

I am using ``APPEND_SLASH = True`` (the default) and usually use a
trailing slash in all of my URL patterns.

This works great for the most part, but some API clients send
POST-requests without the slash and then change the request method to
GET on the subsequent request. In particular, a popular API testing tool
(https://www.getpostman.com/) seems to be affected by this.

I can subclass ``CommonMiddleware`` and set ``response_redirect_class``,
no problem. However, maybe Django should just send HTTP 308 by default?
Is there any reason not to?

-- 
René Fleschenberg

-- 
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/1aa24da3-cd05-317a-b8c1-2a76d707b935%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Default upload permissions

[René Fleschenberg]

Hi,

On 12/5/18 9:54 AM, Carlton Gibson wrote:
> *Proposal*: we should change the default for FILE_UPLOAD_PERMISSION to
> 0o644 (or maybe 0o664), and document that as a backward incompatible
> change. This would be correct for almost all users.  If you're
> deliberately leveraging `FILE_UPLOAD_PERMISSION = None` it's an easy
> switch back to the current behaviour. 
As someone who wasted a couple of hours because of the current behavior,
I am very much in favor of this.

The second-best solution in my opinion would be to have ``manage.py
startproject`` explicitly write the setting, either as 0o644 or as 0o600.

-- 
René Fleschenberg

-- 
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/97d123f7-cf49-0dae-5c2f-171cf421bea7%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: NEW Feature: Collect static order of directories searched. Possible upgrade inside FileSystemFinder.

[René Fleschenberg]

Hi Radosław,

On 03/10/2017 11:49 AM, Radosław Orłowski wrote:
> Right now I'm working with Django 1.8.17 and What I'm trying to
> acomplish is simple override of static files.
> 
> STATICFILES_DIRS = (
> str(os.path.abspath(os.path.join(SITE_ROOT, 'static_new'))),
> str(os.path.abspath(os.path.join(SITE_ROOT, 'static'))),
> )
> 
> STATICFILES_FINDERS = (
> 'django.contrib.staticfiles.finders.FileSystemFinder',
> 'django.contrib.staticfiles.finders.AppDirectoriesFinder',
> )
> 
> my thinking:
> I have to sites that need different logo file.
> 
> Both directories static and static_new have images/logo.png, but this
> file is different.
> 
> I need to add logo from static_new and load rest of content from static
> (js, css. etc)


You mentioned that you have two sites. Are you using the sites
framework? Then you should have a separate settings module for each
site, so you can just give them different settings:


```
# settings_site1.py
# site1 only uses files from ``static``.
SITE_ID = 1
STATIC_ROOT = '/var/static/site1'
STATICFILES_DIRS = (
os.path.abspath(os.path.join(SITE_ROOT, 'static')),
)


# settings_site2.py
# site2 uses files from ``static_new``, and falls back to ``static``
SITE_ID = 2
STATIC_ROOT = '/var/static/site2'
STATICFILES_DIRS = (
    os.path.abspath(os.path.join(SITE_ROOT, 'static_new')),
os.path.abspath(os.path.join(SITE_ROOT, 'static')),
)



Regards,
René

-- 
René Fleschenberg

-- 
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/933e0d82-b0f8-9676-05bc-0d2ab8a5d974%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[René Fleschenberg]

Hi,

> Anyway, it seems that this issue is bound to die in a bikeshedding fest,
> so I’ll leave it there, with my apologies to Brazilian users who will
> remain unable to log into Django-based websites :-(

Please don't let this issue die because we cannot reach consensus between 
60, 100, 192 and 255. That would be silly. Django deserves better.

My personal gut feeling is that I prefer something higher than 60 (because 
why not), but Aymeric has made valid arguments for 60: the practically very 
relevant example of Portugese / Brazilian names plus some margin. If 60 is a 
value that allows us to move this forward without making a core developer 
feel bad about the change, let's go with 60.

I'm +1 on any limit 60+ and -1 on keeping the current limit.

-- 
René Fleschenberg

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

Re: UTF-8 name of a staticfiles test is breaking Django installation

[René Fleschenberg]

Hi everyone,

> Can we consider “update setuptools” to be an adequate resolution for this
> issue?

I realize this is probably not the most substantial argument, but I want to 
mention it anyway: Considering Django's popularity, requiring a recent 
version of setuptools might be a positive side-effect on the larger Python 
ecosystem. The prevalence of old setuptools versions can be rather annoying. 
For example: https://hynek.me/articles/conditional-python-dependencies/

-- 
René Fleschenberg

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

Re: Vendoring multipledispatch

[René Fleschenberg]

Hi,

> Anyway as long as Django is installed in a virtualenv this shouldn't be
> too much of an issue, but I think we should expect some issues from the
> users and these should be documented otherwise people might get
> frustrated.

It can still be an issue for things that share the same virtualenv with 
Django, i.e. Django apps and projects. Any library that Django depends on 
imposes a restriction on which version of this library user code can use.

For example, if Django requires `requests>=2.9,<3.0`, this means that 
Django-based apps and projects cannot use requests 3.0+ in their code (at 
least not easily).

For this reason, I believe that Django should be very conservative about 
introducing new dependencies, but maybe not outrule them completely.

-- 
René

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

Re: slow migrations

[René Fleschenberg]

Hi,

On Saturday 09 January 2016 18:29:32 Shai Berger wrote:
> The other is migrations which *create* data -- fill in tables for
> database- implemented-enums, for example. If you remove these, you are
> going to break your tests (if you do this and haven't broken your tests,
> your tests are missing -- I'd go as far as calling them broken).

I agree with Carl. I avoid Django migrations for this kind of data. 

Obviously, you don't get dependency handling that way, but I think this is 
typically not a problem for this kind of data.

I wonder if this approach should actually be an official recommendation.

-- 
René Fleschenberg

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

startproject values for STATICFILES_DIRS and TEMPLATES

[René Fleschenberg]

Hi,

It is quite common to configure TEMPLATES and STATICFILES_DIRS such that you 
can override the templates and static files of installed apps from some 
central location.

Maybe startproject should actually generate settings to do this by default?

STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)

Or maybe:

STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'mysite', 'static'),
)

In my experience, this is a real pain point for beginners, and doing this 
shouldn't hurt anyone. What do you think?

Also, do you think that templates and static files should be treated 
differently in this regard? The docs currently suggest such a configuration 
for static files, but not for templates. I'd argue that it's more important 
for templates, but it cannot harm to do it for both.

-- 
René Fleschenberg

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