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

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

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

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:

Re: A helpful ImportError for manage.py when Django isn't installed/available

Yes, I always install Django in a virtualenv rather than system-wide. I'm sure there are some users installing it system-wide, but I think that's more and more a niche use case. On Thursday, April 7, 2016 at 4:33:44 PM UTC-4, Rafael Henter wrote: > > Tim Graham, > > How do you install django?

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

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

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

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?

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 =

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

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

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

Re: A helpful ImportError for manage.py when Django isn't installed/available

Tim Graham, How do you install django? Are you using virtualenv ? Best, Rafael Henter On Thursday, March 31, 2016 at 2:15:05 PM UTC-3, Tim Graham wrote: > > Ben Welsh (palewire) raised a proposal on a GitHub pull request [0]: > > I've seen newbies flounder when they receive this error after

Re: Sqlite 3.12 breaks the Django test suite

mkdir ~/sqlite cd ~/sqlite git clone g...@github.com:django/django.git git clone g...@github.com:apollo13/sqlite_bug.git export PYTHONPATH=`pwd`/django cd sqlite_bug gdb python (in gdb shell) r ./manage.py test admin_views Please tell me if this does not cause a segfault for you. Cheers, Florian

Re: Sqlite 3.12 breaks the Django test suite

I've created an application which shows the behavior: https://github.com/apollo13/sqlite_bug -- I cannot yet reproduce it without running it through the testing process -- ./manage.py test admin_views triggers the bug in this application! On Thursday, April 7, 2016 at 3:37:14 PM UTC+2, Florian

Re: Sqlite 3.12 breaks the Django test suite

I was able to reduce the admin_view testcases to https://github.com/apollo13/django/blob/f086934f02efaca272e7e9b29921a31fd47821aa/tests/admin_views/tests.py (see my sqlite_segfault branch) On Thursday, April 7, 2016 at 3:06:14 PM UTC+2, Florian Apolloner wrote: > > Perfect, I can reproduce it.

Re: Sqlite 3.12 breaks the Django test suite

We ran into this issue a couple of months ago - I'm not sure how helpful this is but just in case extra information is useful I'll share our workarounds. The faulthandler output was roughly the same - the error happened during a rollback. This also happened on multiple python and sqlite versions.

Re: Sqlite 3.12 breaks the Django test suite

This is the list of SQL statements we are executing: https://dpaste.de/Mqu1/raw first column is thread id, second is cursor id and third is the statement. I am a little bit confused about why the cursor ids seem to be "jumpy" like that -- but in general this should not cause issues I think On

Re: Sqlite 3.12 breaks the Django test suite

Le jeudi 07 avril 2016, Aymeric Augustin a écrit : > This other ticket about a SQLite segfault may or may not be related: > https://code.djangoproject.com/ticket/24080 Given how old it is, I was tempted to say it's entirely unrelated. But maybe not. I discovered faulthandler thanks to this and

Re: Sqlite 3.12 breaks the Django test suite

Perfect, I can reproduce it. This also happens if the default/other databases are not in memory -- I'll see what happens if I switch to postgres for the second database (though I am getting an error there currently -- might have to fix master :D) On Thursday, April 7, 2016 at 1:00:25 PM UTC+2,

Re: Vendoring multipledispatch

> On Apr 7, 2016, at 1:31 AM, Sylvain Fankhauser > wrote: > > The only problem I can see is dependencies conflicts, where Django would need > package X version > 1.0 and another installed package would need package X > version 0.9. I have this issue with a

Re: Sqlite 3.12 breaks the Django test suite

This other ticket about a SQLite segfault may or may not be related: https://code.djangoproject.com/ticket/24080 -- Aymeric. > On 07 Apr 2016, at 13:00, Raphael Hertzog wrote: > > [ CCing an upstream developer of SQlite too ] > > Hello, > > I did not want to open a ticket

Re: Vendoring multipledispatch

> On Apr 7, 2016, at 8:20 AM, Erik Cederstrand > wrote: > > >> Den 6. apr. 2016 kl. 13.42 skrev Marc Tamlyn : >> >> Does anyone (potentially from OS packaging worlds maybe) have a good reason >> NOT to have a dependency? > > Here is a list

Re: Vendoring multipledispatch

> Den 6. apr. 2016 kl. 13.42 skrev Marc Tamlyn : > > Does anyone (potentially from OS packaging worlds maybe) have a good reason > NOT to have a dependency? Here is a list off the top of my head. This is not necessarily an argument against dependencies, just some things

Sqlite 3.12 breaks the Django test suite

[ CCing an upstream developer of SQlite too ] Hello, I did not want to open a ticket as I'm not sure if the problem is in SQLite or in Django but the Django test suite fails really badly with SQLite 3.12.0 that got recently released (and which is already in Debian Unstable). When using the