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(
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? Ar
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
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 ru
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
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
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.
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.
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
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 the
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,
> 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 project of mine that required six >=
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 as I'm not sure if
> 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 off the top of my head. This is not necessarily an
> 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 to consider.
1: Avail
[ 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 defau
26 matches
Mail list logo
