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-i
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 deliber
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 tem
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/dja
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
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
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.
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
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
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 implem
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(
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
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
> 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.
>
> *
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?
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([
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
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
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 th
19 matches
Mail list logo
