Re: Template handling of undefined variables
Tim and others,
+1 for raising an exception.
Specifically...
I agree that use of undefined variables should raise an exception.
The incompatibility with previous versions will mostly catch errors
that have been going undetected.
Personally, I find it very hard to detect such bugs when reviewing
code written by myself or other team members, especially since we
make heavy use of template inheritance, and we reuse the same
templates from multiple views. So, it's not easy to spot a case
where we forgot to pass a value to a template.
I think Django should at least offer this as an option.
--Fred
Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
On 2/25/17 7:28 PM, Tim Graham wrote:
My proposal was only for the use of undefined variables in template
tags. I didn't realize that the behavior of undefined variables in
some tags resolving to None is documented, but I still think it's a
useful change to raise an exception instead. The philosophy that
template tags shouldn't raise exceptions is more unhelpful than
helpful in my experience. I think the change would be consistent with
the deprecation that starts in Django 1.11 to change {% include %} not
to silencing exceptions and render an empty string, for example.
On Saturday, February 25, 2017 at 4:44:30 PM UTC-5, Karen Tracey wrote:
On Sat, Feb 25, 2017 at 2:10 PM, Tim Graham <timog...@gmail.com
> wrote:
I think any use of undefined template variables should raise
an exception. In the long run, keeping a setting to allow some
other behavior seems confusing and, considering the case of
templates that might be reused in different projects with
different settings, even dangerous.
I think I'm confused...Django templates have allowed use of
undefined variables and documented their use as evaluating to the
empty string for as long as I recall. Wouldn't a change to instead
raise exceptions be a major backwards-incompatibility?
https://docs.djangoproject.com/en/1.7/topics/templates/#variables
<https://docs.djangoproject.com/en/1.7/topics/templates/#variables>
said "If you use a variable that doesn’t exist, the template
system will insert the value of the TEMPLATE_STRING_IF_INVALID
setting, which is set to '' (the empty string) by default."
https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables
<https://docs.djangoproject.com/en/dev/ref/templates/api/#invalid-template-variables>
has refined that doc to note that the behavior is slightly
different in some tags.
Are we really considering changing this behavior to now raise
exceptions?
--
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 post to this group, send email to
django-developers@googlegroups.com
<mailto: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/8b260b00-7921-4977-9521-f61f073e717b%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/8b260b00-7921-4977-9521-f61f073e717b%40googlegroups.com?utm_medium=email_source=footer>.
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/8ff7366a-b8ba-5ac3-566d-6e6258e4ed81%40bristle.com.
For more options, visit https://groups.google.com/d/optout.
Re: Revisiting lazy middleware initialization
Ben, If lazy loading is causing you problems, here's good info on how to force Django to load everything up front, by calling select_related() and prefetch_related() in cases where you need to. And also how to make that the default via use_for_related_fields and custom managers: - https://docs.djangoproject.com/en/1.9/topics/db/optimization/ --Fred Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates. On 3/27/16 4:15 PM, bliyan...@rentlytics.com wrote: I'm not too familiar with the code you're referencing, but I'm personally really annoyed by lazy loading. It has a tendency to make selenium tests timeout inconsistently in CI, as well as give the impression to my bosses that the app is slow rather than just the first load which is usually what they see on new features. -Ben On Thursday, March 24, 2016 at 9:39:50 AM UTC-7, David Evans wrote: Hi all, Currently, middleware is initialized lazily on serving the first request, rather than on application start. There may well have been good reasons for this historically, but I don't think they apply any longer. Lazy initialization is unhelpful if a middleware class throws an error (e.g to report a misconfiguration) because the application will appear to start successfully and only later report the error when a request is made. I'd like to propose initializing middleware when `get_wsgi_application` is called. This solves the problem described above and, as far as I can tell, raises no backwards compatibility issues. More details on all this below. ### 1. Specific example of the problem I recently wrote an adapter for the WhiteNoise static file server so it could function as Django middleware as well as WSGI middleware (https://github.com/evansd/whitenoise <https://github.com/evansd/whitenoise>). WhiteNoise may be unusual in doing a non-trivial amount of work on initialization, but it doesn't seem unreasonable. When used as WSGI middleware any errors are triggered immediately on start up, but not so when used as Django middleware. This makes for a worse developer experience and an increased chance of deployment errors. ### 2. Reasons previously given for lazy initialization There was some brief discussion in this ticket 4 years ago: https://code.djangoproject.com/ticket/18577 <https://code.djangoproject.com/ticket/18577> The reason given there is that "resolving on first request makes most sense, especially for the case where you might not be serving requests at all". Presumably this refers to running non-http-related management commands. But in those cases we never instantiate a WSGI application anyway (wsgi.py is just never imported) so this is no reason not to initialize eagerly when constructing the WSGI application. (Of course, things may have been different 4 years ago.) Another reason is given in the comments in django.core.handles.wsgi: https://github.com/django/django/blob/3c1b572f1815c295878795b183b1957d0df2ca39/django/core/handlers/wsgi.py#L154 <https://github.com/django/django/blob/3c1b572f1815c295878795b183b1957d0df2ca39/django/core/handlers/wsgi.py#L154> This says "Set up middleware if needed. We couldn't do this earlier, because settings weren't available". However `get_wsgi_application` (the only public WSGI API) now calls `django.setup()` before constructing the handler so settings are in fact available. ### 3. Proposed solution My proposal is simply to amend `get_wsgi_application` as follows: def get_wsgi_application(): django.setup(set_prefix=False) handler = WSGIHandler() handler.load_middleware() return handler It's possible that this logic could be moved into the handler's __init__ method. This caused no problems with existing application when I tried it, however it did cause problems with the test suite which seems to rely on the old behaviour in places. The above proposal passes all existing tests as is. ### 4. Backwards compatibility issues Middleware constructors have no means of accessing the request object or anything that depends on it. They are called right at the start of the handler's `__call__` method before the `request_started` signal is sent and before the `script_prefix` thread-local is set. Therefore it cannot matter, from the middleware class's perspective, whether it is instantiated before or after the first request comes in. I'm aware this issue probably isn't high on anyone else's p
Re: [Discussion] Legacy documentation / Boken docs Django v1.2
I vote for a 301 to the matching ReadTheDocs page. I recently had to manually update these bookmarks: - Django 1.4 Docs - Old: https://docs.djangoproject.com/en/1.4/ - New: https://django.readthedocs.org/en/1.4/ - Django 1.4 API Ref - Old: https://docs.djangoproject.com/en/1.4/ref/ - New: https://django.readthedocs.org/en/1.4/ref/ - Django 1.4 Doc Detailed TOC - Old: https://docs.djangoproject.com/en/1.4/contents/ - New: https://django.readthedocs.org/en/1.4/contents.html - Django 1.4 Doc Index - Old: https://docs.djangoproject.com/en/1.4/genindex/ - New: https://django.readthedocs.org/en/1.4/genindex.html - Django 1.4 Module Index - Old: https://docs.djangoproject.com/en/1.4/py-modindex/ - New: https://django.readthedocs.org/en/1.4/py-modindex.html - Django 1.4 Testing - Old: https://docs.djangoproject.com/en/1.4/topics/testing/ - New: https://django.readthedocs.org/en/1.4/topics/testing.html - Django 1.4 Testing Assertions - Old: https://docs.djangoproject.com/en/1.4/topics/testing/#assertions - New: https://django.readthedocs.org/en/1.4/topics/testing.html#assertions - Django 1.5 Docs - Old: https://docs.djangoproject.com/en/1.5/ - New: https://django.readthedocs.org/en/1.5.x/ - Django 1.6 Docs - Old: https://docs.djangoproject.com/en/1.6/ - New: https://django.readthedocs.org/en/1.6.x/ --Fred Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates. On 2/17/16 5:21 AM, Daniel Chimeno wrote: IMHO We should keep the older version of docs somewhere, ReadTheDocs it's fine. But we can't only remove them. We may notice the users instead of returning a simple 404. There are a lot of people still using those versions. To keep happy search engines, we should give a 301 to somewhere, not sure if we should do it or not. El jueves, 7 de agosto de 2014, 13:32:25 (UTC+2), Areski Belaid escribió: Hi Folks, I wanted to open a discussion regarding the following ticket https://code.djangoproject.com/ticket/23042 <https://code.djangoproject.com/ticket/23042> To summarize briefly, you may notice that we can search doc for Django version 1.2 (for example https://docs.djangoproject.com/search/?q=forms=4 <https://docs.djangoproject.com/search/?q=forms=4>) but the links in the result won't work. As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach to solve this problem: 1) Fix the docs builder for versions < 1.2 (at the moment the doc-building process is broken on old branches due to different version of Sphinx) 2) Discontinue older Django docs version and decide a policy regarding doc hosting What do you think? -- //Areski -- 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 post to this group, send email to django-developers@googlegroups.com <mailto: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/ba425446-63fb-4039-b238-443adac456ed%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/ba425446-63fb-4039-b238-443adac456ed%40googlegroups.com?utm_medium=email_source=footer>. 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/56C5D635.9020500%40bristle.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: Django website redesign launched
+1 for keeping it courteous. The Django community is far and away the most helpful e-group of people I've seen in 30 years of programming in dozens of languages. That post was much ruder than anything I've ever seen on a Django forum, and did deserve to be addressed. Thanks, Danielle! --Fred Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates. On 12/17/14 6:13 AM, Baptiste Mispelon wrote: Hi Torsten, As far as I know, it's not often that people get kicked out of this mailing list (note that Christian was kicked out, not banned, so he can join back if he'd like) so I'm not sure what's "customary". However, we strive to create a friendly and inclusive community here, so toxic and insulting behavior is not simply ignored. In this instance, I think Daniele's response was appropriate and I stand by it too. I hope that answers your question. Cheers, Baptiste PS: The mailing list is publicly viewable at https://groups.google.com/forum/#!forum/django-developers. It's only for posting here that you need to be registered. On 12/17/2014 11:29 AM, Torsten Bronger wrote: Hallöchen! Daniele Procida writes: [...] In the meantime I have removed you from our email lists, since your tone is not welcome here. Please don't come back unless you can communicate in a more acceptable way. Is this customary procedure on this mailing list in such cases? Normally one simply ignores postings/authors one doesn't like. I hope that banned users don't have the answers to my questions. ;-) Besides, a sock puppet is made in minutes ... Tschö, Torsten. -- 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/549376A5.3000108%40bristle.com. For more options, visit https://groups.google.com/d/optout.
Re: Multiple template engines for Django - week 1
Excellent! Thanks for the update. I donated to the IndieGoGo campaign. --Fred Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates. On 10/12/14 2:31 PM, Aymeric Augustin wrote: Hello, I just posted the first update on this project: https://myks.org/en/multiple-template-engines-for-django/#2014-10-12 My work in progress on the DEP is available here: https://myks.org/en/multiple-template-engines-for-django/dep/ Feedback is welcome, especially on sections I've described as "done" in the update. Thanks, -- 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/543AFE2D.5050304%40bristle.com. For more options, visit https://groups.google.com/d/optout.
