Re: Django template 'if ... is' feature design

[Stephen Kelly]

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]

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

[Stephen Kelly]

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

[Carl Meyer]

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: A helpful ImportError for manage.py when Django isn't installed/available

[Tim Graham]

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? 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 running 
>> manage.py.
>>
>> $ python manage.py
>> Traceback (most recent call last):
>>   File "manage.py", line 7, in 
>> from django.core.management import execute_from_command_line
>> ImportError: No module named django.core.management
>>
>> The root cause is almost always simple, like forgetting install Django 
>> with pip or neglecting to "activate" a virtual environment. But the Python 
>> jargon doesn't do much to help people new to our world connect the dots. 
>>
>> My proposal: Catch that error and print out a more verbose message that 
>> explains to the user exactly what's wrong. Here's my draft. I'd welcome any 
>> changes, but I think something along these lines could better welcome new 
>> people into Django.
>>
>> Traceback (most recent call last):
>>   File "manage.py", line 11, in 
>> installed and available on your PATH variable?")
>> ImportError: Couldn't import Django. Are you sure it's installed and 
>> available on your PYTHONPATH environment variable? Did you forget to 
>> activate a virtual environment?
>>
>>
>>
>> -
>> Claude says, "I'm not convinced about this. Aren't we hiding other 
>> possibly helpful import errors (at least on Python 2)?"
>> Aymeric says, "I share Claude's concern. We've been constantly removing 
>> that sort of "helpful" exception wrapping from Django"
>> Aymeric again, after further investigation, "Importing 
>> django.core.management doesn't ripple too far. Specifically it doesn't 
>> import any of the user's code. This reduces the likelihood of masking 
>> useful errors. It will mask exception info if Django is installed 
>> incorrectly, for instance because two installs happened in the same 
>> location (but I think that's less likely since pip/virtualenv became 
>> mainstream and since we added code to setup.py to detect existing installs).
>>
>> Does anyone else have opinions on the change? I suppose another option 
>> could be to try to reraise the original exception with the "helpful 
>> message" added.
>>
>>
>> [0] https://github.com/django/django/pull/6314
>>
>

-- 
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/4ad80dce-716f-4232-be0e-c6cfe559ad27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django template 'if ... is' feature design

[Stephen Kelly]

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]

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

[Ryan Hiebert]

> 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

[Stephen Kelly]

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

[Daniel Chimeno]

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

[Stephen Kelly]

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

[Ryan Hiebert]

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

[Stephen Kelly]

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: A helpful ImportError for manage.py when Django isn't installed/available

[Rafael Henter]

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 running 
> manage.py.
>
> $ python manage.py
> Traceback (most recent call last):
>   File "manage.py", line 7, in 
> from django.core.management import execute_from_command_line
> ImportError: No module named django.core.management
>
> The root cause is almost always simple, like forgetting install Django 
> with pip or neglecting to "activate" a virtual environment. But the Python 
> jargon doesn't do much to help people new to our world connect the dots. 
>
> My proposal: Catch that error and print out a more verbose message that 
> explains to the user exactly what's wrong. Here's my draft. I'd welcome any 
> changes, but I think something along these lines could better welcome new 
> people into Django.
>
> Traceback (most recent call last):
>   File "manage.py", line 11, in 
> installed and available on your PATH variable?")
> ImportError: Couldn't import Django. Are you sure it's installed and 
> available on your PYTHONPATH environment variable? Did you forget to 
> activate a virtual environment?
>
>
>
> -
> Claude says, "I'm not convinced about this. Aren't we hiding other 
> possibly helpful import errors (at least on Python 2)?"
> Aymeric says, "I share Claude's concern. We've been constantly removing 
> that sort of "helpful" exception wrapping from Django"
> Aymeric again, after further investigation, "Importing 
> django.core.management doesn't ripple too far. Specifically it doesn't 
> import any of the user's code. This reduces the likelihood of masking 
> useful errors. It will mask exception info if Django is installed 
> incorrectly, for instance because two installs happened in the same 
> location (but I think that's less likely since pip/virtualenv became 
> mainstream and since we added code to setup.py to detect existing installs).
>
> Does anyone else have opinions on the change? I suppose another option 
> could be to try to reraise the original exception with the "helpful 
> message" added.
>
>
> [0] https://github.com/django/django/pull/6314
>

-- 
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/5cd2ada4-e61e-4cb3-9fad-a71cce3d29d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Florian Apolloner]

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

On Thu, Apr 7, 2016, at 06:07 PM, Richard Hipp wrote:
> On 4/7/16, Florian Apolloner  wrote:
> > 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!
> 
> I have not touched Python in over a decade.  Please help me track down
> the problem by giving me step-by-step instructions on how to get this
> test running, inside of gdb, on Ubuntu 14.04.3 LTS.
> -- 
> D. Richard Hipp
> d...@sqlite.org

-- 
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/1460046444.1161220.572000497.6B596361%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Florian Apolloner]

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 Apolloner wrote:
>
> 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 Thursday, April 7, 2016 at 3:06:14 PM UTC+2, Florian Apolloner wrote:
>>
>> 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, 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 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 default --parallel run, I get many weird 
>>> errors and sometimes even a deadlock. When I run it with --parallel=1, 
>>> I got a segfault. 
>>>
>>> You can see a log of the failure here (this is a parallel run): 
>>>
>>> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
>>>  
>>>
>>> There's a backtrace of the segfault (with --parallel=1): 
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
>>>  
>>>
>>> Cheers, 
>>>
>>> PS: Tracked here in Debian too: 
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225 
>>> -- 
>>> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer 
>>>
>>> Discover the Debian Administrator's Handbook: 
>>> → http://debian-handbook.info/get/ 
>>>
>>

-- 
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/3bc96d8b-5004-4412-9802-c8532182fec2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Florian Apolloner]

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. 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, 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 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 default --parallel run, I get many weird 
>> errors and sometimes even a deadlock. When I run it with --parallel=1, 
>> I got a segfault. 
>>
>> You can see a log of the failure here (this is a parallel run): 
>>
>> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
>>  
>>
>> There's a backtrace of the segfault (with --parallel=1): 
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
>>  
>>
>> Cheers, 
>>
>> PS: Tracked here in Debian too: 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225 
>> -- 
>> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer 
>>
>> Discover the Debian Administrator's Handbook: 
>> → http://debian-handbook.info/get/ 
>>
>

-- 
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/e4a298a0-e873-4578-9b55-4583bb3faa3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Sam Cooke]

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.

It started when we removed a model and the one foreign key to that model.
The quickest workaround we found was to simply add the model and foreign
key back when running tests - which implies to me that the structure of the
database was related to whether or not it segfaulted (the test where the
segfault occurred was unrelated to the model that was removed).

The second option was we could remove the creation of a model during a test
(i.e. something that meant a rollback was required).

The third option was to use an on-disk sqlite database rather than in
memory.

I hope some of that is useful,
Sam

On Thu, 7 Apr 2016 at 14:37 Florian Apolloner  wrote:

> 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 Thursday, April 7, 2016 at 3:06:14 PM UTC+2, Florian Apolloner wrote:
>>
>> 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, 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 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 default --parallel run, I get many weird
>>> errors and sometimes even a deadlock. When I run it with --parallel=1,
>>> I got a segfault.
>>>
>>> You can see a log of the failure here (this is a parallel run):
>>>
>>> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
>>>
>>> There's a backtrace of the segfault (with --parallel=1):
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
>>>
>>> Cheers,
>>>
>>> PS: Tracked here in Debian too:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225
>>> --
>>> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer
>>>
>>> Discover the Debian Administrator's Handbook:
>>> → http://debian-handbook.info/get/
>>>
>> --
> 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/813967fd-3a1f-4b2a-93cc-c14f320f920f%40googlegroups.com
> 
> .
> 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/CAMyx3A1YcqPkzUNboc%3DntngpAyLjLJ_9gy5vfZ_b5pxyqGjZrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Florian Apolloner]

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 Thursday, April 7, 2016 at 3:06:14 PM UTC+2, Florian Apolloner wrote:
>
> 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, 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 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 default --parallel run, I get many weird 
>> errors and sometimes even a deadlock. When I run it with --parallel=1, 
>> I got a segfault. 
>>
>> You can see a log of the failure here (this is a parallel run): 
>>
>> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
>>  
>>
>> There's a backtrace of the segfault (with --parallel=1): 
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
>>  
>>
>> Cheers, 
>>
>> PS: Tracked here in Debian too: 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225 
>> -- 
>> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer 
>>
>> Discover the Debian Administrator's Handbook: 
>> → http://debian-handbook.info/get/ 
>>
>

-- 
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/813967fd-3a1f-4b2a-93cc-c14f320f920f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Raphael Hertzog]

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 stacktrace
appears in the same place (rollback handling):

$ cd tests
$ LANG=C PYTHONPATH=.. python3 -X faulthandler ./runtests.py --verbosity=2 
--parallel=1 admin_views.tests.AdminViewBasicTest
[...]
test_popup_dismiss_related (admin_views.tests.AdminViewBasicTest) ... ok
Fatal Python error: Segmentation fault

Current thread 0x7fab40575700 (most recent call first):
  File 
"/home/rhertzog/deb/pkg/python-django/django/db/backends/sqlite3/base.py", line 
321 in execute
  File "/home/rhertzog/deb/pkg/python-django/django/db/backends/utils.py", line 
62 in execute
  File "/home/rhertzog/deb/pkg/python-django/django/db/backends/base/base.py", 
line 288 in _savepoint_rollback
  File "/home/rhertzog/deb/pkg/python-django/django/db/backends/base/base.py", 
line 328 in savepoint_rollback
  File "/home/rhertzog/deb/pkg/python-django/django/db/transaction.py", line 
243 in __exit__
  File "/home/rhertzog/deb/pkg/python-django/django/test/testcases.py", line 
1016 in _rollback_atomics
  File "/home/rhertzog/deb/pkg/python-django/django/test/testcases.py", line 
1073 in _fixture_teardown
  File "/home/rhertzog/deb/pkg/python-django/django/test/testcases.py", line 
919 in _post_teardown
  File "/home/rhertzog/deb/pkg/python-django/django/test/testcases.py", line 
217 in __call__
  File "/usr/lib/python3.5/unittest/suite.py", line 122 in run
  File "/usr/lib/python3.5/unittest/suite.py", line 84 in __call__
  File "/usr/lib/python3.5/unittest/runner.py", line 176 in run
  File "/home/rhertzog/deb/pkg/python-django/django/test/runner.py", line 494 
in run_suite
  File "/home/rhertzog/deb/pkg/python-django/django/test/runner.py", line 533 
in run_tests
  File "./runtests.py", line 275 in django_tests
  File "./runtests.py", line 458 in 

Maybe SQLite 3.12 makes it more likely to trigger to the problem or something
like that. I can reproduce the crash with Python 2 and Python 3.

Cheers,
-- 
Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

-- 
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/20160407131413.GA26492%40home.ouaza.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Florian Apolloner]

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, 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 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 default --parallel run, I get many weird 
> errors and sometimes even a deadlock. When I run it with --parallel=1, 
> I got a segfault. 
>
> You can see a log of the failure here (this is a parallel run): 
>
> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
>  
>
> There's a backtrace of the segfault (with --parallel=1): 
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
>  
>
> Cheers, 
>
> PS: Tracked here in Debian too: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225 
> -- 
> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer 
>
> Discover the Debian Administrator's Handbook: 
> → http://debian-handbook.info/get/ 
>

-- 
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/d74755bd-b281-4d29-88c1-884719ed26a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[Donald Stufft]

> 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 >= 
> 1.10 and for some reason Xcode on OSX with the system Python (ie. not 
> installed with brew for example) forces you to have six 1.9, which comes 
> before in the PYTHONPATH. I know that Lektor  for 
> example solves this by having an install script 
>  that creates a virtualenv and installs 
> it inside this virtualenv.
> 
Yea. This is a problem with OS X Python from the system. They ship a bunch of 
libraries that are on the sys.path by default but which can’t be replaced (even 
more so in the most recent version of OS X when SIP is turned on which prevents 
installing anything into the system Python as well). This issue has been 
reported to Apple and I think there is a good chance that they’ll have it fixed 
in a way that a user can install packages into.

Overall though, users shouldn’t install things into their system Python which I 
think is supported by the fact that the system Python on recent versions of OS 
X are not writable, even with sudo, unless you disable one of the major 
security components of your machine. That doesn’t affect just any potential 
dependencies Django might have, but also Django itself.

> Also James mentioned that "back in the days pip wasn't as awesome as it is 
> today", but we have to keep in mind that a lot of OSes still use an old pip 
> version by default (Debian stable for example ships pip 1.5 
> ).
> 

pip 1.5 is new enough that you get most of the reliability benefits. Major 
things it’s missing are:

* Implicit wheel cache, allowing sdists to only be compiled once and the built 
binaries reused between installs.
* Implicit http cache, allowing files to only need to be downloaded once.
* Manylinux1 support, allowing people to publish binary wheels for Linux 
systems to PyPI.
* Conditional dependencies inside of a sdist without a hack workaround.

Minor, but nice quality of life things are:

* Massively reduced verbosity on install.
* Nicer progress bars.

> Anyway as long as Django is installed in a virtualenv this shouldn't be too 
> much of an issue, but I think we should expect some issues from the users and 
> these should be documented otherwise people might get frustrated.
> 
> Cheers,
> Sylvain
> 

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/CCC99F08-1813-4E09-AE4B-B5E4BF58F618%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Sqlite 3.12 breaks the Django test suite

[Aymeric Augustin]

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 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 default --parallel run, I get many weird
> errors and sometimes even a deadlock. When I run it with --parallel=1,
> I got a segfault.
> 
> You can see a log of the failure here (this is a parallel run):
> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
> 
> There's a backtrace of the segfault (with --parallel=1):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
> 
> Cheers,
> 
> PS: Tracked here in Debian too:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225
> -- 
> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer
> 
> Discover the Debian Administrator's Handbook:
> → http://debian-handbook.info/get/
> 
> -- 
> 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/20160407110012.GA18876%40home.ouaza.com.
> 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/ADA26AA4-2560-44E0-8EBD-CB275DCA51B6%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring multipledispatch

[Donald Stufft]

> 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 argument 
> against dependencies, just some things to consider.
> 
> 
> 1: Availability. If Django depends on version x.y.z and x.y.z is removed from 
> PyPI, or the whole package is deleted, then Django is no longer installable 
> (google "NPM kik" for a recent example).
> 
> 2: Customization. We need to tweak functionality in some non-upstreamable 
> way, cherry-pick new functionality, or fix security issues before they are 
> published on PyPI.
> 
> 3: Version conflicts, as mentioned by Sylvain.
> 
> 4: Security/stability. We depend on version x.y and a witty developer uploads 
> dependency x.y.z+1 with an Easter egg, or the PyPI developer account is 
> hacked and x.y is replaced.
> 
> 
> These issues are amplified in a world where many people have automated 
> production deployments running 'pip install -U -r requirements.txt'. Issues 
> could spread very fast.
> 
> This may not be much different than what people are already exposed to with 
> their own project dependencies, but vendoring (directly or by dependency) is 
> endorsement by the Project, so any issues in the dependencies will fall back 
> on the Project.
> 


For 1, 3, and 4, Django is already exposed to these problems for the vast 
majority of use cases since if you want to use any database other than SQLite 
then you have to install something or if you want to use an ImageField, or 
bcrypt, etc. Having ``pip install Django`` work but not ``pip install Django 
psycopg2`` when you’re running a site that uses PostgreSQL doesn’t get you 
anything extra there.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/989F87C0-B9E1-4745-BCFC-ED19DC61C37F%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Vendoring multipledispatch

[Erik Cederstrand]

> 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: Availability. If Django depends on version x.y.z and x.y.z is removed from 
PyPI, or the whole package is deleted, then Django is no longer installable 
(google "NPM kik" for a recent example).

2: Customization. We need to tweak functionality in some non-upstreamable way, 
cherry-pick new functionality, or fix security issues before they are published 
on PyPI.

3: Version conflicts, as mentioned by Sylvain.

4: Security/stability. We depend on version x.y and a witty developer uploads 
dependency x.y.z+1 with an Easter egg, or the PyPI developer account is hacked 
and x.y is replaced.


These issues are amplified in a world where many people have automated 
production deployments running 'pip install -U -r requirements.txt'. Issues 
could spread very fast.

This may not be much different than what people are already exposed to with 
their own project dependencies, but vendoring (directly or by dependency) is 
endorsement by the Project, so any issues in the dependencies will fall back on 
the Project.


Erik

-- 
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/19C24081-78F8-4790-9302-84BFB4AC0A46%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Sqlite 3.12 breaks the Django test suite

[Raphael Hertzog]

[ 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 default --parallel run, I get many weird
errors and sometimes even a deadlock. When I run it with --parallel=1,
I got a segfault.

You can see a log of the failure here (this is a parallel run):
https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz

There's a backtrace of the segfault (with --parallel=1):
https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1

Cheers,

PS: Tracked here in Debian too:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225
-- 
Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

-- 
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/20160407110012.GA18876%40home.ouaza.com.
For more options, visit https://groups.google.com/d/optout.