Re: Newline stripping in templates: the dnl way
On Fri, Feb 24, 2012 at 9:45 AM, Tom Evans wrote:
> In your folder are:
> {^ for item in folder ^}
> {{ item }},
> {^ endfor ^}
>
> This would render as "In your folder are: item1,item2,item3,"
>
> Changing some of the carets:
>
> In your folder are:
> {% for item in folder ^}
> {{ item }},
> {^ endfor %}
>
> This would render as "In your folder are:\nitem1,item2,item3,\n"
Fwiw, I had a different solution to this problem once, which I implemented
in a project using jinja to generate configuration files:
1. Prior to processing the template, replace all blank lines with a
tag (e.g. "BLANKLINE").
2. After processing the template, remove all blank lines.
3. Remove all instances of BLANKLINE, which restores the blank lines
the author intended.
This works remarkably well, and the output is easy to predict by the
template author. For the case you mentioned above, you would still need to
join the lines, though:
{% for item in folder %}{{ item }},{% endfor %}
Aron
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Ticket 9722 (pynotify support)
I've noticed that the auto-reload support isn't kind to my laptop battery, so I was happy to find that somebody's already done the work to get inotify support into the autoreloader. The patches are in https://code.djangoproject.com/ticket/9722 This ticket seems to have been around for a while without an owner. Is there something I can do to help get it in? Thanks, Aron -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket 9722 (pynotify support)
Hi Jacob, Sounds great. I'll update the patch and see if I can come up with some tests. Thanks! Aron On Mon, Oct 29, 2012 at 5:32 PM, Jacob Kaplan-Moss wrote: > Hi Aron -- > > Thanks for the interest; looks like a pretty nice addition. > > Looking at the patch, I see a couple things you could do to help it > get in quicker: > > * Update the patch so that it applies against he latest development > trunk. Looks like the patch is 2+ years old, so the chances are it > will no longer apply. You could then upload a new patch to the tracker > or open a pull request over on GitHub and note the pull-request number > in Trac. > > * There's no documentation or tests, both of which are usually needed > to get a patch accepted. There probably doesn't need to be much in the > way of documentation -- just a note that if pynotify is installed that > it'll be used. Testing's another story: this is likely to be something > that's really tricky to test. If you come to the conclusion that this > simply can't be tested than that might be OK, but you should > explicitly explain your reasoning behind testing on the ticket page. > > Thanks! > > Jacob > > On Mon, Oct 29, 2012 at 4:16 PM, Aron Griffis > wrote: > > I've noticed that the auto-reload support isn't kind to my laptop > battery, > > so I was happy to find that somebody's already done the work to get > inotify > > support into the autoreloader. The patches are in > > https://code.djangoproject.com/ticket/9722 > > > > This ticket seems to have been around for a while without an owner. Is > there > > something I can do to help get it in? > > > > Thanks, > > Aron > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django developers" group. > > To post to this group, send email to django-developers@googlegroups.com. > > To unsubscribe from this group, send email to > > django-developers+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: improving debug logging in development
On Mon, 2015-03-23 at 19:16 -0600, Carl Meyer wrote:
> And it still seems to me that it's bad for Django's default config to
> set `level: ERROR` and `propagate: False` on the django.request and
> django.security loggers, as that prevents those logs from propagating to
> higher-level handlers someone may want to install.
My fix for this has been the following snippet in settings.py:
# The DEFAULT_LOGGING dict is unhelpful and resides even with
# disable_existing_loggers=True. This prevents propagation to the root
# logger for loggers defined in DEFAULT_LOGGING.
from django.utils.log import DEFAULT_LOGGING
DEFAULT_LOGGING['loggers'] = {}
-Aron
--
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/1427163497.27346.3.camel%40arongriffis.com.
For more options, visit https://groups.google.com/d/optout.
Re: Fixing makemessages for Javascript
On Thursday, April 14, 2011 12:30:56 PM UTC-4, Jannis Leidel wrote: > > On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote: > > > I think I agree with Ned here: I can't see the downside to fixing it > > on the release branch. "It violates our policy" doesn't count IMO: > > it's *our* policy, and we get to break it if there's a good reason. > > Making translation in JavaScript work is a good reason as I see it. > > FTR I agree we have an issue here, I just disagree with the proposed fix. > If you think we can adopt Babel in the release branch, let's do it. > I haven't posted here before, or made any contribution to Django thus far, so I recognize in advance that my opinion isn't worth much. However I'm a Django user who would benefit from a solution to the Javascript messages problem, so I'd like to register my voice. :-) I'm in favor of Ned's patch for 1.3.x then switching to Babel in 1.4. As I see it, there are two points in favor of Ned's patch: readiness and risk. Regarding readiness, Ned's patch is drop-in and the Babel work hasn't been done yet. Regarding risk, Ned's patch fixes known-terrible-brokenness in Javascript message parsing without introducing much risk, whereas switching to Babel carries some (perhaps minor) risk of regressing existing 1.3 installations so it deserves soaking in the development tree for a while. It's interesting to me that Ned pointed out some JS syntax that Babel misparses but Ned's jslex gets right, suggesting that Babel may still need work too. Thanks, Aron -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible Bug in RegexURLResolver
On Tue, Jul 12, 2016 at 3:25 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > def _populate(self): > with self._lock: > if self._populated: > return > # … populate … > self._populated = True > Depending on how frequently the code is called, it might be worthwhile to check self._populated prior to obtaining the lock. def _populate(self): if self._populated: return with self._lock: if self._populated: return # ... populate ... self._populated = True This way the only time you're waiting on the lock is when you actually need to be waiting on the lock, i.e. while another thread is populating. -Aron -- 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/CADu1%3D220Hmiqq-MeH3gSRtW9C2eqmS7A3jZ%2B25dSiPPcsa%3DzVw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
