Re: Django template 'if ... is' feature design
Hi Tim, due to Stephen's response, my concerns are not valid. :) Still, my comments among your lines: Am Freitag, 15. April 2016 02:30:46 UTC+2 schrieb Tim Graham: > > Here are some examples of when the "is" operator isn't equivalent to "==". > > http://stackoverflow.com/questions/3647692/when-is-the-operator-not-equivalent-to-the-is-operator-python > It's true that "==" is not the same as "is". I just wanted to say that most sane cases are probably YAGNI. Especially in the light of the increased complexity for template users. > Preston (author of the patch to add the "is" operator [0]) indicated > support for "is" was necessary for template-based widget rendering [1]. I > haven't studied that patch closely, but maybe if you take a look you'll > understand why it's needed. > Mmm, I couldn't see a good use-case, though. :( > I don't see much benefit to your proposal of limiting its usage to > comparing boolean/None values. > Neither do I, given that "== True", "== False" and "== None" will do the trick. Sven -- 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/dbf49a98-1080-45a6-b7d9-c9f406cd39f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Am Donnerstag, 14. April 2016 21:04:04 UTC+2 schrieb Stephen: > > > 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. > > Thanks for clarifying. I didn't know that exactly this was a deliberate choice. I always got the impression that Django tries to boil down the feature set of its template engine for very good reasons (which I agree with). Sven -- 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/89ae41f3-8be7-4b83-8e66-4b2aa26a3809%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
Hi Sven, Here are some examples of when the "is" operator isn't equivalent to "==". http://stackoverflow.com/questions/3647692/when-is-the-operator-not-equivalent-to-the-is-operator-python Preston (author of the patch to add the "is" operator [0]) indicated support for "is" was necessary for template-based widget rendering [1]. I haven't studied that patch closely, but maybe if you take a look you'll understand why it's needed. I don't see much benefit to your proposal of limiting its usage to comparing boolean/None values. [0] https://code.djangoproject.com/ticket/26118 [1] https://github.com/django/django/pull/4848 On Wednesday, April 13, 2016 at 4:35:34 PM UTC-4, 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. > > > I can contribute here to the "design consideration" that from my > experience with other (less experienced) developers it that the difference > of "is" and "==" is not quite easy to explain (as illustrated by this > thread as well). So, I am not 100% convinced that "is" and "is not" is a > valid use-case for a template language but I may miss some important piece > here. > > > However, given the docs and tests added in the patch, it seems the > intended use-case for this kind of feature is to check for "is None", "is > not None", "is True", "is not True" etc. Would it makes sense to hard-wire > those specific use-cases instead? > > (Admittedly, even those can be implemented using "==".) > -- 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/47be46cb-5224-4f9e-8f92-986839c25658%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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
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. I can contribute here to the "design consideration" that from my experience with other (less experienced) developers it that the difference of "is" and "==" is not quite easy to explain (as illustrated by this thread as well). So, I am not 100% convinced that "is" and "is not" is a valid use-case for a template language but I may miss some important piece here. However, given the docs and tests added in the patch, it seems the intended use-case for this kind of feature is to check for "is None", "is not None", "is True", "is not True" etc. Would it makes sense to hard-wire those specific use-cases instead? (Admittedly, even those can be implemented using "==".) -- 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/2e5471b6-2e0a-4098-8056-53787ba75b83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
On 08/04/16 01:40, Stephen Kelly wrote: > Carl Meyer wrote: > >> 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. I'd be in favor of a documentation note like that, or a link to Python documentation of `is`. I agree about not duplicating Python documentation, but a short note like that could help many people who aren't that familiar with Python in general. Tobias -- 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/57077644.20103%40cutebit.de. For more options, visit https://groups.google.com/d/optout.
Re: Django template 'if ... is' feature design
On Thursday, 7 April 2016 23:21:37 UTC+1, Ryan Hiebert wrote: > > > > On Apr 7, 2016, at 5:13 PM, Stephen Kelly > wrote: > > > * Why is there no 'is not' operator? ie '{% if a is not True %}' > > `is not` is probably logical addition, if somebody wants to put in the > time to make it happen. I've created a ticket #26479 to add `is not`. -- 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/b72221ac-5ec1-4ce2-9d2e-4635b97d115f%40googlegroups.com. 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
Hi Steve, On 04/07/2016 05:09 PM, Stephen Kelly wrote: > Am I right to think that using 'is' with numbers is expected to work like > this in the DTL? : The situation with integers is roughly the same as with strings, except that I believe CPython interns _all_ small integers, not just those that are literals in the code. This happens to make DTL appear a bit more "consistent" with CPython for integers, but the correct advice is still the same: don't ever use `is` with integers, whether in Python code or DTL. The `is` operator tells you whether two variables refer to the same object. This is sometimes a meaningful question to ask for instances of classes with mutable state, or for singletons like None, True, and False, but it's not a useful or meaningful question to ask about immutable objects like strings and integers, because there is no perceptible difference (other than from `is`, `id`, and perhaps memory usage) resulting from whether the implementation happened to choose to reuse the same object or not. > 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'? No to tests, because we would be adding tests for undefined and unreliable behavior. 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. Carl -- 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/5706EAB6.6070207%40oddbird.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
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
Hi Steve, On 04/07/2016 04:36 PM, Stephen Kelly wrote: > 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. 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. Carl -- 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/5706E49B.6080302%40oddbird.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
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
> On Apr 7, 2016, at 5:13 PM, Stephen Kelly wrote: > > 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? I don't know about the docs, but it _does_ work exactly like the Python version. 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 > * Why is there no 'is not' operator? ie '{% if a is not True %}' `is not` is probably logical addition, if somebody wants to put in the time to make it happen. -- 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/E2798027-D059-461B-BCE5-2C43AC48CEC8%40ryanhiebert.com. 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
The *is* comparator is quite error prone for misunderstanding it (as we could observed some times) maybe it worths to link python docs about it: https://docs.python.org/3.5/reference/expressions.html#is Well, that Python docs doesn't say to much (lack of examples) >>> a = 'pub' >>> b = ''.join(['p','u','b']) >>> a == b True >>> a is b False a == b it's the same as id(a) == id(b) I think we should give an emphasis on this because are going to cause problems to some people. Hope it helps. El jueves, 7 de abril de 2016, 23:43:21 (UTC+2), Stephen escribió: > > 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/d94f9eac-469f-48cf-bb73-09fe17572f9e%40googlegroups.com. 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.
Re: Django template 'if ... is' feature design
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. 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. > On Apr 7, 2016, at 4:42 PM, Stephen Kelly wrote: > > 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. -- 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/4FEBF18F-960B-4650-AE49-0E03D7E84AF3%40ryanhiebert.com. 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.