Re: Django template 'if ... is' feature design
Sven R. Kunze wrote: > Good evening everybody. That's my first post here, so let's how this > works. :) > > This particular discussion caught my sight as it might introduce something > really "low-level" functionality into the template engine. As far as I understand from https://github.com/django/django/pull/6442 it it deliberate that the if tag exposes the entire implementation detail. That is, if the current if tests didn't exist today and they were submitted, they would be rejected as unnecessary because the existing tests are really just testing the python if operator behavior. That's what I understand, but I might have misinterpreted something. Thanks, Steve. -- 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/neopi5%242el%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Carl Meyer wrote: > No to tests, because we would be adding tests for undefined and > unreliable behavior. Yes, makes sense. Thanks again for the explanation. > It might be worth adding a short documentation note. We largely want to > avoid documenting Python's behavior in the Django docs, but a short note > in the template `is` docs reminding people not to ever use `is` with > strings or numbers might be worthwhile. Or to only use it with None, True or False. However, as you say it doesn't make sense to document python in the django docs. If it's only me who would be confused about this, there may be no need to change anything in the docs either. Thanks, Steve. -- 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/ne6r57%24i6b%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Carl Meyer wrote:
> The point is that you shouldn't ever expect any consistent behavior when
> using `is` with strings (whether in Python code or in Django templates),
> because that behavior is not defined by the Python language, it's
> implementation dependent. It happens that the CPython implementation
> interns short string literals, so they are the same object in memory,
> but this doesn't happen for longer strings, or strings that aren't
> generated from literals. Those "string literals" in the Django template
> are not string literals from Python's perspective, so they are not
> interned, so they are not the same object.
>
> There's no reasonable way to "fix" this, because there is no reliable
> Python behavior to try to match. Any fix would just be encouraging use
> of `is` with strings; the right answer is "never use `is` with strings"
> (or with integers, for exactly the same reasons).
>
> In other words, the value of `"string" is "string"` in Python is
> effectively accidental and almost certainly useless (it does correctly
> and reliably tell you whether the two string objects are the same
> object, but for immutable objects this information is
> performance-optimization-dependent and useless), so there is no
> "correct" behavior here for the DTL to match.
I see, and I understand now. Thanks for the explanation and sorry for being
slow on the uptake on this one!
Am I right to think that using 'is' with numbers is expected to work like
this in the DTL? :
In [120]: c["a"] = 1
In [121]: t = e.from_string("{% if 1 is 1 %}yes{% else %}no{% endif %}")
In [122]: print t.render(c)
yes
In [123]: t = e.from_string("{% if 1 is a %}yes{% else %}no{% endif %}")
In [124]: print t.render(c)
yes
In [125]: c["a"] = 1.0
In [126]: t = e.from_string("{% if 1 is a %}yes{% else %}no{% endif %}")
In [127]: print t.render(c)
no
In [128]: t = e.from_string("{% if 1 is 1.0 %}yes{% else %}no{% endif
%}")
In [129]: print t.render(c)
no
In [130]: t = e.from_string("{% if 1.0 is 1.0 %}yes{% else %}no{% endif
%}")
In [131]: print t.render(c)
no
Would it be useful to add those as unit tests and document what can be
expected of 'if ... is'?
Thanks,
Steve.
--
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/ne6pap%24n52%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Ryan Hiebert wrote:
>> * What should work / what should not work? Is the documentation clear?
>
> I don't know about the docs, but it _does_ work exactly like the Python
> version.
I suppose you are not responding to what you quoted.
Anyway, that makes at least two people telling me that
In [81]: "True" is "True"
Out[81]: True
and
In: t = e.from_string(
"{% if \"True\" is \"True\" %}yes{% else %}no{% endif %}")
In: t.render(c)
Out: 'no'
is 'the same behavior' and seems to be what you expect.
> A while back I had this same confusion regarding the `is`
> operator. You can see all about it in my Stack Overflow question:
> http://stackoverflow.com/q/8638880/206349
Your question doesn't relate to the django template system, so I'm afraid I
don't understand how it is 'the same confusion' or relates to what this
thread is about.
Thanks!
Steve.
--
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/ne6ndh%24ku1%242%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Stephen Kelly wrote:
> * The unit tests added both have the same name ("template"). They should
> have different names of the form 'if-tag-isNN'
FYI, I made a pull request which fixes this and some other minor issues in
the if-tag tests:
https://github.com/django/django/pull/6430
If it's not trivial to integrate in master, I can file a trac ticket soon to
track it.
Thanks,
Steve.
--
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/ne6mkh%24c6d%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Daniel Chimeno wrote:
> I think we should give an emphasis on this because are going to cause
> problems to some people.
Yes, this is why I suggested in my original mail that the feature needs more
design consideration.
* What should work / what should not work? Is the documentation clear?
* Why is there no 'is not' operator? ie '{% if a is not True %}'
Thanks,
Steve.
--
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/ne6m22%242gp%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Ryan Hiebert wrote: > The `is` operator in Python checks for identical objects. A string is not > guaranteed to be exactly the same object as another string (in this > example "True" is not the same object (bytes in memory) as the second > "True", so Python rightly sees that they are not the same object. I'm sorry, I don't understand what you're saying here. In [81]: "True" is "True" Out[81]: True In [82]: a = "anything" In [83]: b = "anything" In [84]: a is b Out[84]: True In [85]: a = "any" + "thing" In [86]: a is b Out[86]: True In [87]: a = "any" In [88]: a += "thing" In [89]: a is b Out[89]: False > True, False, and None are singletons, that are guaranteed to always point > to the exact same object in memory, and `is` is the appropriate operator > to use there. It is for those singletons that this feature is being added. Ok. I'm not usually a python programmer, so I don't know what kind of expectations people have of 'if ... is' in templates. Given the behavior of python, I find the behavior surprising. Perhaps it should be documented. The documentation doesn't currently say that 'if ... is' only works for True, False and None. If that is the case, then it probably should be documented. (and the unit tests should be renamed :)) Thanks, Steve. -- 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/ne6ksv%24j7m%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
Django template 'if ... is' feature design
Hello,
I reviewed
https://github.com/django/django/commit/c00ae7f5
while updating the features of Grantlee, and I have the following notes:
* The unit tests added both have the same name ("template"). They should
have different names of the form 'if-tag-isNN'
* The feature does not work the same way as django 'is' works. For example:
In: t = e.from_string(
"{% if \"True\" is \"True\" %}yes{% else %}no{% endif %}")
In: t.render(c)
Out: 'no'
The feature 'if ... is' feature looks like it needs more design
consideration before it is released.
Thanks,
Steve.
--
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/ne6k90%249b3%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Re: Newline stripping in templates: the dnl way
Leon Matthews wrote: > On 2 March 2012 09:45, Carl Meyer > wrote: >> Same reason any ticket stalls - it seems that nobody felt strongly >> enough about it to put the time into reviewing and thoroughly testing >> the patch and marking it Ready for Checkin. If you'd like to see it in >> (post 1.4 at this point, of course), feel free to do that! > > Done! :-) > > I've created a new version of the patch against Django 1.5-dev, which > passes all tests, etc... > > I've attached it to the ticket directly: > https://code.djangoproject.com/ticket/2594 > > Cheers, > > Leon > Oh, interesting that this is getting interest again. I think I emailed the list annually about it without getting a reply :). I'll review again soon too. Thanks, Steve. -- 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: Reversing translated urls in templates
Jannis Leidel wrote:
>
> On 05.07.2011, at 09:26, Jonathan Slenders wrote:
>
>> I'm also +1 on {% language lang_code %}... {% endlanguage %}
>>
>> We are using exactly this template tag for maybe about half a year
>> already. Not for i18n urls, but for formatting numbers. The decimal
>> separator in Dutch is a comma, but sometimes we want to be sure to
>> have a dot a some part of the template. (When rendering SVG, JSON or
>> other markup lanugages.)
>>
>> So, this is certainly a very versatile approach.
>
> Great, thanks all for your opinions, I actually went ahead yesterday
> and added it in https://code.djangoproject.com/changeset/16501
>
> Jannis
>
Isn't this about more than language, but also locale?
In Grantlee I implemented this as a with_locale tag:
http://gitorious.org/grantlee/grantlee/blobs/master/examples/contacts/themes/linguist/sleepy/main.html
And then eg dates are also localized:
http://steveire.files.wordpress.com/2010/11/contacts_multi_lang_headers.png
--
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: DDN: #2594 (Template system whitespace) may cause blocktrans issue
Jonathan Slenders writes: > > Some concerns, even if I don't know much about the subject. > > Are you sure that it's always appropriate to strip indentation? I didn't say anything about 'always' :) -- 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.
DDN: #2594 (Template system whitespace) may cause blocktrans issue
Hi, I posted this before but I think people had the 1.3 release on the
brain, so now that's out (congrats :)), I'm trying again:
http://thread.gmane.org/gmane.comp.python.django.devel/30752
** copied content **
#2594 is now ready for checkin as far as I can tell for the 1.4 milestone (I
understand 1.3 is closed), with one side-issue.
http://code.djangoproject.com/ticket/2594
The side issue is that msgids in the .po file extracted with makemessages
will not match the untranslated string that Django calls gettext with in the
case where a blocktrans tag is used like this:
{% blocktrans %}
Something
{% endblocktrans %}
It seems that makemessages could create a msgid with
'\n Something\n ', and the blocktrans tag would try to retrieve the msgid:
'\n Something', ie, no 'trailing' whitespace from the line that
{% endblocktrans %} is on, if the settings when creating messages does not
match the in-production settings.
This issue may be solved by
http://code.djangoproject.com/ticket/5849
but it's hard to tell because Malcolm Tredinnick didn't cover this
particular issue in the mailing list thread and I'm not sure it was
considered.
So the DDN is one of the following options I think (brainstorming):
0) Ignore the issue. State that makemessages must be run with the same
settings as the production site.
1) Patch /django/utils/translation/trans_real.py to strip the last line if
it is only whitespace and a blocktrans tag is being processed. Then the
#2594 patch can be committed. Affected msgids might have to be retranslated
or have a fuzzy marker removed. When looking up the msgid for a blocktrans,
try first with the given input, then if that fails, try again with the last
line stripped if it is space. That way it would work with and without the
whitespace trimming setting.
The patch might look something like this (untested, just for illustration):
diff --git a/django/utils/translation/trans_real.py
b/django/utils/translation/trans_real.py
index a5c612b..2a7dfe8 100644
--- a/django/utils/translation/trans_real.py
+++ b/django/utils/translation/trans_real.py
@@ -272,6 +272,18 @@ def do_translate(message, translation_function):
from django.conf import settings
_default = translation(settings.LANGUAGE_CODE)
result = getattr(_default, translation_function)(eol_message)
+if not result:
+ try_again = False
+ counter = 0
+ for char in eol_message[::-1]:
+ if not char.isspace():
+ break
+ counter += 1
+ if char == '\n':
+ try_again = True
+ break
+ if try_again:
+ return do_translate(eol_message[:-counter], translation_function)
if isinstance(message, SafeData):
return mark_safe(result)
return result
@@ -421,6 +433,12 @@ endblock_re = re.compile(r"""^\s*endblocktrans$""")
plural_re = re.compile(r"""^\s*plural$""")
constant_re = re.compile(r"""_\(((?:".*?")|(?:'.*?'))\)""")
+def join_with_trimmed_trailing_newline(lines):
+result = ''.join(lines[:-1])
+if not lines[-1].isspace():
+result += lines[-1]
+return result
+
def templatize(src, origin=None):
"""
Turns a Django template into something that is understood by xgettext.
It
@@ -449,13 +467,16 @@ def templatize(src, origin=None):
pluralmatch = plural_re.match(t.contents)
if endbmatch:
if inplural:
-out.write(' ngettext(%r,%r,count) ' %
(''.join(singular), ''.join(plural)))
+S = join_with_trimmed_trailing_newline(singular)
+P = join_with_trimmed_trailing_newline(plural)
+out.write(' ngettext(%r,%r,count) ' % (S, P))
for part in singular:
out.write(blankout(part, 'S'))
for part in plural:
out.write(blankout(part, 'P'))
else:
-out.write(' gettext(%r) ' % ''.join(singular))
+S = join_with_trimmed_trailing_newline(singular)
+out.write(' gettext(%r) ' % S)
for part in singular:
out.write(blankout(part, 'S'))
intrans = False
2) Solve #5849, thereby making it a blocking issue for #2594, but
making the msgid issue described above an issue for #5849. That means the
#2594 patch can't be committed until #5849 is resolved. Depending on the
resolution of #5894, there may be some effect on existing msgids.
3) Close #2594 and #5894 as WONTFIX.
I don't expect (0) is acceptable, (1) is my favorite, (2) might be workable
depending on how this issue is resolved in #5849 and (3) gets my -1 because
#2594 makes this so much nicer when doing code generation for example.
All the best,
Steve.
--
You received this message because you are subs
Re: Comments no longer possible on djangobook.com?
Alex Gaynor wrote: > Hi Steve, > > The DjangoBook is not part of the Django Project itself, so this isn't > really the right place to report a bug with it: > http://djangobook.com/contact/ is the appropriate way to try and get into > contact with the authors. Ok done, thanks. > > Alex > -- 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.
Comments no longer possible on djangobook.com?
Hi, I think someone here runs that site. Are the comments all gone or am I missing something? Thanks, Steve. -- 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: Various small issues
Klaas van Schelven wrote: > Hi all, > > Maybe I wasn't clear enough last time... I've provided patches for > both these old problems and would appreciate either a brutal Linus > style rant for being such an idiot or would like to see the patches > applied. Silence... not so much. > Hi Klass, Your post is understandable but unfortunately timed. I am in the same boat as you in that I would like my issues attended to. However, a feature of the django development process, as far as I can tell, is that once a future django version has had blockers assigned and tickets marked with that milestone, nothing else is likely to get attention unless it sparks someones particular interest, even tickets which are 'done', 'obvious' or 'trivial'. Another feature of the django development process is that issues with tickets don't get forgotten. The best we can do is wait a week after the 1.3 release and then re-post if you think they're still overlooked. All the best, Steve. -- 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.
DDN: #2594 (Template system whitespace) may cause blocktrans issue
Hi,
#2594 is now ready for checkin as far as I can tell for the 1.4 milestone (I
understand 1.3 is closed), with one side-issue.
http://code.djangoproject.com/ticket/2594
The side issue is that msgids in the .po file extracted with makemessages
will not match the untranslated string that Django calls gettext with in the
case where a blocktrans tag is used like this:
{% blocktrans %}
Something
{% endblocktrans %}
It seems that makemessages could create a msgid with
'\n Something\n ', and the blocktrans tag would try to retrieve the msgid:
'\n Something', ie, no 'trailing' whitespace from the line that
{% endblocktrans %} is on, if the settings when creating messages does not
match the in-production settings.
This issue may be solved by
http://code.djangoproject.com/ticket/5849
but it's hard to tell because Malcolm Tredinnick didn't cover this
particular issue in the mailing list thread and I'm not sure it was
considered.
So the DDN is one of the following options I think (brainstorming):
0) Ignore the issue. State that makemessages must be run with the same
settings as the production site.
1) Patch /django/utils/translation/trans_real.py to strip the last line if
it is only whitespace and a blocktrans tag is being processed. Then the
#2594 patch can be committed. Affected msgids might have to be retranslated
or have a fuzzy marker removed. When looking up the msgid for a blocktrans,
try first with the given input, then if that fails, try again with the last
line stripped if it is space. That way it would work with and without the
whitespace trimming setting.
The patch might look something like this (untested, just for illustration):
diff --git a/django/utils/translation/trans_real.py
b/django/utils/translation/trans_real.py
index a5c612b..2a7dfe8 100644
--- a/django/utils/translation/trans_real.py
+++ b/django/utils/translation/trans_real.py
@@ -272,6 +272,18 @@ def do_translate(message, translation_function):
from django.conf import settings
_default = translation(settings.LANGUAGE_CODE)
result = getattr(_default, translation_function)(eol_message)
+if not result:
+ try_again = False
+ counter = 0
+ for char in eol_message[::-1]:
+ if not char.isspace():
+ break
+ counter += 1
+ if char == '\n':
+ try_again = True
+ break
+ if try_again:
+ return do_translate(eol_message[:-counter], translation_function)
if isinstance(message, SafeData):
return mark_safe(result)
return result
@@ -421,6 +433,12 @@ endblock_re = re.compile(r"""^\s*endblocktrans$""")
plural_re = re.compile(r"""^\s*plural$""")
constant_re = re.compile(r"""_\(((?:".*?")|(?:'.*?'))\)""")
+def join_with_trimmed_trailing_newline(lines):
+result = ''.join(lines[:-1])
+if not lines[-1].isspace():
+result += lines[-1]
+return result
+
def templatize(src, origin=None):
"""
Turns a Django template into something that is understood by xgettext.
It
@@ -449,13 +467,16 @@ def templatize(src, origin=None):
pluralmatch = plural_re.match(t.contents)
if endbmatch:
if inplural:
-out.write(' ngettext(%r,%r,count) ' %
(''.join(singular), ''.join(plural)))
+S = join_with_trimmed_trailing_newline(singular)
+P = join_with_trimmed_trailing_newline(plural)
+out.write(' ngettext(%r,%r,count) ' % (S, P))
for part in singular:
out.write(blankout(part, 'S'))
for part in plural:
out.write(blankout(part, 'P'))
else:
-out.write(' gettext(%r) ' % ''.join(singular))
+S = join_with_trimmed_trailing_newline(singular)
+out.write(' gettext(%r) ' % S)
for part in singular:
out.write(blankout(part, 'S'))
intrans = False
2) Solve #5849, thereby making it a blocking issue for #2594, but
making the msgid issue described above an issue for #5849. That means the
#2594 patch can't be committed until #5849 is resolved. Depending on the
resolution of #5894, there may be some effect on existing msgids.
3) Close #2594 and #5894 as WONTFIX.
I don't expect (0) is acceptable, (1) is my favorite, (2) might be workable
depending on how this issue is resolved in #5849 and (3) gets my -1 because
#2594 makes this so much nicer when doing code generation for example.
All the best,
Steve.
--
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...@goo
DDN: Localize anything with _(this_syntax) ?
Hi,
Currently strings in templates can be translated with {{ _("foo") }} syntax.
Localizing values can be done with a filter {{ foo|localize }}.
I have a patch to allow localizing localizable values like {{ _(foo) }},
which I think is more convenient. It sort of mixes up the meaning of _() to
be both for translatable strings and localizable dates and numbers, so I
thought I'd ask before finishing the patch and filing a ticket whether that
is something people want/think is ok.
In [1]: from django.template import Template, Context
In [2]: import datetime
In [3]: t = Template("{{ _(foo) }} -- {{ _(bar) }} -- {{ _(100.001) }}")
In [4]: c = Context({ "foo" : 11, "bar" : datetime.date.today() })
In [5]: t.render(c)
Out[5]: u'100,001 -- Nov. 11, 2010 -- 100.001'
(Locale is en_US)
All the best,
Steve.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Receipt for mail to security@ ?
Jacob Kaplan-Moss wrote: > On Wed, Nov 10, 2010 at 1:39 PM, Stephen Kelly > wrote: >> Can someone confirm that the email I sent yesterday made it through? Last >> time I emailed that list it was marked as spam apparently. > > Yes, we've got it. We'll get back to you shortly - sorry for the delay. No rush, sorry. Just wanted to make sure it wasn't in the spam again. Steve -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Receipt for mail to security@ ?
Hi, Can someone confirm that the email I sent yesterday made it through? Last time I emailed that list it was marked as spam apparently. All the best, Steve. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: custom function for autoescape
Hi,
Sorry I'm late to this thread. I've been working hard on i18n.
Luke Plant wrote:
> Logically I would expect the following 3 to produce the same output:
>
> 1) I use mark_safe on my safe input string and use addslashes to add
> the slashes
>
> Template("{{ val|addslashes }}").render(
> Context({'val': mark_safe("Joe's string")},
> autoescape=rtfescape)
> )
>
> 2) I don't use mark_safe on my safe input string and use addslashes to
> add the slashes
>
> Template("{{ val|addslashes }}").render(
> Context({'val': "Joe's string"},
> autoescape=rtfescape)
> )
>
> 3) I manually 'apply' addslashes.
>
> Template("{{ val }}").render(
> Context({'val': "Joe\\'s string"},
> autoescape=rtfescape)
> )
>
> But these do not produce the same output - 1 is different from 2 and 3,
> and is not what I intend.
>
Just for clarity could you say what the three outputs would be?
1) Joe\'s string
2) Joe\\'s string
3) Joe\\'s string
?
I would say that you would need to be aware of the escaping rules of the
mark up you are templating when writing your template, just like you need to
be aware of html escaping rules when you do any of these:
1)
Template("{{ val|force_escape }}").render(
Context({'val': mark_safe("This & that")})
)
2)
Template("{{ val|force_escape }}").render(
Context({'val': "This & that"})
)
3)
Template("{{ val }}").render(
Context({'val': "This & that"})
)
If you don't have knowledge of the escaping rules, and base the filters you
use based on that knowledge, you're in the same situation.
Flipped around, though, the |upper filter is not safe (in html and in
django), so that would mean that
Template("{{ val|upper }}").render(
Context({'val': mark_safe("Joe\\'s string")},
autoescape=rtfescape)
Would unexpectedly escape Joe's string to "JOE'S STRING", even though
upper is not unsafe in rtf.
That means that the safe-ness or not of each filter is determined by the
template markup being prepared.
So I see your point, and I see why it adds unwanted mess to Django. I just
thought I'd give more points of information. I'll probably even remove the
feature from Grantlee when I can, so thanks for the discussion.
All the best,
Steve.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature proposal: escape hatch for colliding template syntax in django templates
Stephen Kelly wrote:
> Stephen Kelly wrote:
>
>> Łukasz Rekucki wrote:
>>
>>> On 19 October 2010 23:41, Jacob Kaplan-Moss
>>> wrote:
>>>> On Tue, Oct 19, 2010 at 4:31 PM, James Bennett
>>>> wrote:
>>>>> If we're going to do this, could we also look at deprecating the
>>>>> 'templatetag' template tag? There are a couple cases a 'verbatim' tag
>>>>> wouldn't cover that 'templatetag' wouldn't, but I'm kinda hard-pressed
>>>>> to think of when they'd ever come up in reality.
>>>>
>>>> Good idea.
>>>>
>>>> Maybe combine them? {% verbatim "{{{" %} or {% verbatim %} ... {%
>>>> endverbatim %}
>>
>> I'm pretty sure the current lexer for django templates can't handle this
>> very well.
>
> Sorry. Sent too early. All thumbs today. Consider these examples:
>
> {% verbatim "%} %}" %}
>
> (That is, "%} %}" in a verbatim-no-end tag)
>
> {% verbatim %} %} %} {% endverbatim %}
>
> (That is, " %} %} " wrapped in verbatim tags)
>
> The current lexer uses regexps to find tokens like that. It would need to
> be completely rewritten/redesigned to handle these cases.
One option might be to extend the template syntax with {$ verbatim $}
(I know that's not a popular suggestion)
Normal text {$ Verbatim {% text {% {{ %} $}
It would be simple to add, but of course it still leaves the same issue of
using the '$}' inside the tokens.
>
> All the best,
>
> Steve.
>
>>
>>
>>>
>>> We could also add something like a "boundary" argument just in case
>>> someone will want to escape "{% endverbatim %}":
>>>
>>> {% verbatim boundary="my_random_string" %}{% endverbatim %}{%
>>> endverbatim_my_random_string %}
>>>
>>>
>>
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature proposal: escape hatch for colliding template syntax in django templates
Stephen Kelly wrote:
> Łukasz Rekucki wrote:
>
>> On 19 October 2010 23:41, Jacob Kaplan-Moss
>> wrote:
>>> On Tue, Oct 19, 2010 at 4:31 PM, James Bennett
>>> wrote:
>>>> If we're going to do this, could we also look at deprecating the
>>>> 'templatetag' template tag? There are a couple cases a 'verbatim' tag
>>>> wouldn't cover that 'templatetag' wouldn't, but I'm kinda hard-pressed
>>>> to think of when they'd ever come up in reality.
>>>
>>> Good idea.
>>>
>>> Maybe combine them? {% verbatim "{{{" %} or {% verbatim %} ... {%
>>> endverbatim %}
>
> I'm pretty sure the current lexer for django templates can't handle this
> very well.
Sorry. Sent too early. All thumbs today. Consider these examples:
{% verbatim "%} %}" %}
(That is, "%} %}" in a verbatim-no-end tag)
{% verbatim %} %} %} {% endverbatim %}
(That is, " %} %} " wrapped in verbatim tags)
The current lexer uses regexps to find tokens like that. It would need to be
completely rewritten/redesigned to handle these cases.
All the best,
Steve.
>
>
>>
>> We could also add something like a "boundary" argument just in case
>> someone will want to escape "{% endverbatim %}":
>>
>> {% verbatim boundary="my_random_string" %}{% endverbatim %}{%
>> endverbatim_my_random_string %}
>>
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature proposal: escape hatch for colliding template syntax in django templates
Łukasz Rekucki wrote:
> On 19 October 2010 23:41, Jacob Kaplan-Moss
> wrote:
>> On Tue, Oct 19, 2010 at 4:31 PM, James Bennett
>> wrote:
>>> If we're going to do this, could we also look at deprecating the
>>> 'templatetag' template tag? There are a couple cases a 'verbatim' tag
>>> wouldn't cover that 'templatetag' wouldn't, but I'm kinda hard-pressed
>>> to think of when they'd ever come up in reality.
>>
>> Good idea.
>>
>> Maybe combine them? {% verbatim "{{{" %} or {% verbatim %} ... {%
>> endverbatim %}
I'm pretty sure the current lexer for django templates can't handle this
very well.
>
> We could also add something like a "boundary" argument just in case
> someone will want to escape "{% endverbatim %}":
>
> {% verbatim boundary="my_random_string" %}{% endverbatim %}{%
> endverbatim_my_random_string %}
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: How to get patches from 'Accepted' to 'Committed'
Jacob Kaplan-Moss wrote: > A polite nag on the mailing list -- like this email -- is a perfect > way to prod things along. > Cool, thanks for committing those. All the best, Steve. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
How to get patches from 'Accepted' to 'Committed'
Hi, The diagram here shows the lifecycle of a ticket. http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage What I don't get is how a ticked goes from 'Accepted' to 'Ready for checkin' The context I ask in is in relation to patches I submitted a year ago and which were accepted: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&reporter=~steveire&order=priority Should I change the status to 'Ready for checkin' myself or is somebody else supposed to? I'd like to contribute more small patches to Django, but I must say it's demotivating that those haven't seen any action since being accepted, and I couldn't see what I need to do to get those committed. If someone can tell me what's missing that's something I can work with. All the best, Steve. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Grantlee version 0.1.0 now available
The Grantlee community is pleased to announce the availability of Grantlee version 0.1.0[1]. Grantlee is a Free Software string template library written in Qt and based on the syntax and design of the Django template system[2]. Django's template system is designed to separate content and presentation with a clean and easy yet powerful syntax. As it is based on Django, there is already a community of designers familiar with the syntax, and a community of developers implementing logical fixes and writing new extensions. Qt APIs and existing strengths are central to the design of Grantlee. * QVariant is used for type independance * QObject and QMetaObject are used for type and property introspection * Template files and external media can be loaded through the QtResource system. * Template syntax can be extended using the QtPlugin class * Plugins can be implemented in QtScript or in C++. * The Granltee core library requires only QtCore * The Grantlee gui library provides tools for using QTextDocument with the template system. * Grantlee documentation[3] is compatible with QtAssistant More information can be found in the KDE dot article[4]. The API of Grantlee will be stable for 0.1.x releases, but will likely change in minor ways for the 0.2.0 release. Grantlee uses an open git repository for development. Patches can be submitted through gitorious[5]. Feedback regarding Grantlee APIs is welcome and should be sent to kde-...@kde.org. [1] http://downloads.grantlee.org [2] http://docs.djangoproject.com/en/dev/topics/templates/ [3] http://grantlee.org/apidox/ [4] http://dot.kde.org/2010/04/12/grantlee-version-010-out [5] http://gitorious.org/grantlee -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: NDjango - .Net port of Django template langauage
Michael Feingold wrote:
>
> Thank you for the pointers. You have some pretty interesting test
> cases in your project.
Thanks. Actually most of the credit goes to the django developers, because
most of my tests are just ported versions of the django tests.
> We also have quiet a few test cases in our unit
> tests have a peek if you are interested.
Yes, I will.
> As to the ticket - this is an
> interesting one. The scenario it refers to seems pretty clear to me I
> agree with Karen's judjment on the issue. Nested block definitions and
> block.super variables in itself seem clear to me and it appears to
> work fine in our testing. But here is the scenario I cannot find a
> miningful interpretation for:
>
> === base template ===
> {% block b %}
> whatever
> {% endblock b %}
>
> === child template ===
> {% extends base %}
> {% block new %}
> {% for k in list %}
> {% block b %}
> new value: {{k}}
> {% endblock %}
> {% endfor %}
> {% endblock new %}
The first issue is that the block new is not defined in the base template.
See the unit test inheritance14:
http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/templates/tests.py#L757
That means that the block new will not be rendered, and any variables
created in that context will not be defined. However, as block b is defined
in the base, django searches for b in the child anywhere in its node tree.
It is found and rendered in the right place, but as "k" is undefined, the
output is simply "\nnew value: \n".
If block new was defined in the base template, the situation would be
different, and I think it's covered in the tests I posted before where the
block b would be rendered for each value in the list. I'm not certain
whether that behaviour is desired or undefined.
All the best,
Steve.
>
> assuming that there let's say 6 values in the list what is the
> expected result here? The child template defines 6 different variants
> to be placed in a single hole? which one goes? The first? the last?
> all of them? Nested block definition is ok when we define a 'hole',
> but when we define a new value to be placed in a hole it creates
> ambiguity for which I do not see any real use.
>
> On Sep 23, 2:22 pm, Stephen Kelly
> wrote:
>> Michael Feingold wrote:
>> > On Sep 23, 2:54 am, Pablo Escobar
>> > wrote:
>> >> 1. Django is Open Source. It is not a problem to find the parsing
>> >> algorithm
>>
>> > Of course it is And we did go through the code. But reverse
>> > engineering can show you what happens, not what the intention was
>>
>> Usually the unit tests are the best documentation there. However I
>> noticed that in this case there are no unit tests for blocks being
>> nested.
>>
>> I am also the author of a port of the Django system, to C++/Qt in my
>> case.
>>
>> http://www.gitorious.org/grantlee/pages/Home
>>
>> I wrote some tests for nesting of blocks here:
>>
>> http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8...
>>
>> Which I'm sure I'll eventually port back up to django. The end result
>> seems to be that {{ block.super }} can behave in ways that you might not
>> expect when blocks are nested.
>>
>> I also found this ticket which probably explains the behaviour I see in
>> the tests when using block.super:
>>
>> http://code.djangoproject.com/ticket/7324
>>
>> All the best,
>>
>> Steve.
>
--~--~-~--~~~---~--~~
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: NDjango - .Net port of Django template langauage
Michael Feingold wrote:
> On Sep 23, 2:54 am, Pablo Escobar
> wrote:
>> 1. Django is Open Source. It is not a problem to find the parsing
>> algorithm
>>
> Of course it is And we did go through the code. But reverse
> engineering can show you what happens, not what the intention was
Usually the unit tests are the best documentation there. However I noticed
that in this case there are no unit tests for blocks being nested.
I am also the author of a port of the Django system, to C++/Qt in my case.
http://www.gitorious.org/grantlee/pages/Home
I wrote some tests for nesting of blocks here:
http://www.gitorious.org/grantlee/grantlee/commit/85c47cd951e155008a8a5241a7bb2ef8dd018e82
Which I'm sure I'll eventually port back up to django. The end result seems
to be that {{ block.super }} can behave in ways that you might not expect
when blocks are nested.
I also found this ticket which probably explains the behaviour I see in the
tests when using block.super:
http://code.djangoproject.com/ticket/7324
All the best,
Steve.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
