Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID

[Yo-Yo Ma]

I may be way off base here, but I actually feel like string_if_invalid should 
eventually be removed. It seems like a really bad idea to have a setting that 
can muck up an application in unexpected ways. Meanwhile, settings like 
DEBUG=True can't muck up your application, even if they're not secure to leave 
on in production.

I think the answer to whether it should be treated as a regression is the 
inverse of whether there are other places where template logic could 
unexpectedly change based on this setting. Fixing this one situation by 
checking for a specific error seems wrong, unless it's the only such case that 
could be reasonably expected to cause this problem. Based on the warning in the 
docs (about the admin), I take it that is not the case.

So without further ado, I vote "not a regression".

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4431f173-db1f-4b5d-9941-1ca1fb4697e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django dashboard packages?

[Allison A.]

Hi all, 

I'd like to get an idea of what dashboard packages Django developers prefer 
or are using instead of the out-of-the-box admin. 

Allison


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/38e16d7b-4aaa-451a-b848-4b657ca703b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Technical board report - 1.8 release cycle

[Aymeric Augustin]

Sorry, I missed one discussion:

6bis. December 29th, 2014: accepting DEP 182 (Multiple Template Engines). 
Decision: yes.

-- 
Aymeric.



> On 10 nov. 2015, at 20:41, Aymeric Augustin 
>  wrote:
> 
> Hello,
> 
> It recently occurred to the team that, in the interest of transparency and 
> accountability, the technical board should publish a report on its activity 
> at the end of each term.
> 
> As a reminder, the technical board is a group of five people elected among 
> the Django team who holds two prerogatives: making major technical decisions 
> and removing or vetoing a grant of commit access.
> 
> 
> Here’s the report from September 7th, 2014 to March 31st, 2015.
> 
> Activity was low. This is a good! It means that decisions were made by 
> consensus within the community and the team. No disagreement had to be 
> resolved by a vote of the technical board.
> 
> We applied the “no veto to new team members” rule by voting on each proposal. 
> Most of these votes were formalities because the technical board members had 
> already expressed their opinion on the team’s mailing list.
> 
> I just looked at the documentation and realized that our organization doesn’t 
> require such positive votes. It merely allows negative votes. Perhaps we 
> could cut down that bureaucracy.
> 
> Here’s the detail of the discussions held on the mailing-list.
> 
> 1. September 12th, 2014: adding Michael Manfre to the team with commit 
> access. Decision: yes.
> 
> 2. September 14th, 2014: discussion about the unsettings project, both on the 
> process and technical aspects. No decision put to vote.
> 
> 3. Septembre 19th, 2014: discussion about the name of this list. Decision: 
> change it to "Django Developers (contributions to Django itself)”. 
> 
> 4. September 24th, 2014: adding Tom Christie to the team without commit 
> access. Decision: yes.
> 
> 5. October 1st, 2014: adding Collin Anderson to the team without commit 
> access. Decision: yes.
> 
> 6. October 8th, 2014: adding Curtis Maloney to the team without commit 
> access. Decision: yes.
> 
> 7. January 8th, 2015: adding Markus Holtermann to the team with commit 
> access. Decision: yes.
> 
> 8. January 29th, 2015: adding Ola Sitarska and Ola Sendecka to the team 
> without commit access. Decision: yes.
> 
> 
> I’ll send a similar email for the 1.9 release cycle when it’s over.
> 
> If someone knows a better place than the mailing-list archives to store this 
> information, let me know.
> 
> Best regards,
> 
> -- 
> Aymeric.
> 
> 
> 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F4B4BB0A-FFBA-4ACE-84D3-610AD6C96E3E%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: add new template tag "age"

[Jamie Norrish]

On Tue, 2015-11-10 at 18:50 +, Marc Tamlyn wrote:

> Agreed, this does not belong on core. In particular the formatting of
> a duration varies widely depending on the expected age range,
> languages and site context. Naturaltime is one implementation, the
> specific case you seem to be hinting at is a count of years, which is
> definitely too particular for Django inclusion. would make a perfect
> third party app though!

Further, age (for people, at least) is measured in different ways
around the world. See for example https://en.wikipedia.org/wiki/East_As
ian_age_reckoning

Jamie

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1447184150.4351.2.camel%40artefact.org.nz.
For more options, visit https://groups.google.com/d/optout.

Technical board report - 1.8 release cycle

[Aymeric Augustin]

Hello,

It recently occurred to the team that, in the interest of transparency and 
accountability, the technical board should publish a report on its activity at 
the end of each term.

As a reminder, the technical board is a group of five people elected among the 
Django team who holds two prerogatives: making major technical decisions and 
removing or vetoing a grant of commit access.


Here’s the report from September 7th, 2014 to March 31st, 2015.

Activity was low. This is a good! It means that decisions were made by 
consensus within the community and the team. No disagreement had to be resolved 
by a vote of the technical board.

We applied the “no veto to new team members” rule by voting on each proposal. 
Most of these votes were formalities because the technical board members had 
already expressed their opinion on the team’s mailing list.

I just looked at the documentation and realized that our organization doesn’t 
require such positive votes. It merely allows negative votes. Perhaps we could 
cut down that bureaucracy.

Here’s the detail of the discussions held on the mailing-list.

1. September 12th, 2014: adding Michael Manfre to the team with commit access. 
Decision: yes.

2. September 14th, 2014: discussion about the unsettings project, both on the 
process and technical aspects. No decision put to vote.

3. Septembre 19th, 2014: discussion about the name of this list. Decision: 
change it to "Django Developers (contributions to Django itself)”. 

4. September 24th, 2014: adding Tom Christie to the team without commit access. 
Decision: yes.

5. October 1st, 2014: adding Collin Anderson to the team without commit access. 
Decision: yes.

6. October 8th, 2014: adding Curtis Maloney to the team without commit access. 
Decision: yes.

7. January 8th, 2015: adding Markus Holtermann to the team with commit access. 
Decision: yes.

8. January 29th, 2015: adding Ola Sitarska and Ola Sendecka to the team without 
commit access. Decision: yes.


I’ll send a similar email for the 1.9 release cycle when it’s over.

If someone knows a better place than the mailing-list archives to store this 
information, let me know.

Best regards,

-- 
Aymeric.



-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/E34AA440-8FB9-472F-9782-AA351BB5CA03%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID

[Tim Graham]

I'd appreciate some opinions on whether or not we should treat this issue 
as a regression: https://code.djangoproject.com/ticket/25600

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e0818b8e-e8dc-47ec-b23d-e1e66f358a96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle GIS update

[Tim Graham]

The changes to get it running were merged in September. Absent a proper 
solution for those 6 failures, I agree it would be a good idea to mark them 
expectedFailure so we can get the build running on CI before 1.9 final.

On Tuesday, November 10, 2015 at 1:54:42 PM UTC-5, Marc Tamlyn wrote:
>
> Thanks for getting it running at all!
>
> It looks to me like those tests just need to be less accurate for Oracle, 
> good plan.
>
> Did you have any specific changes to make to get it to run at all? If so 
> we should include those soon, irrespective of whether the fixes for these 
> other tests make it into 1.9 final.
>
> Marc
> On 5 Nov 2015 8:21 pm, "Jani Tiainen" > 
> wrote:
>
>> Hi, I finally had time to get back on Oracle GIS issues. 
>>
>> I ran test suite against 1.9.x and 7 tests fails.
>>
>> 3 tests are most probably due different algorithms used to calculate 
>> geographical distance and areas. My proposal for fix is to use backend 
>> spesific values.
>>
>> Failing testcases are:
>> ==
>> FAIL: test_distance_function 
>> (gis_tests.geogapp.tests.GeographyFunctionTests)
>> AssertionError: 4899.67677194225 != 4891.2 within 2 places
>> ==
>> FAIL: test_geography_area (gis_tests.geogapp.tests.GeographyFunctionTests)
>> AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
>> ==
>> FAIL: test06_geography_area (gis_tests.geogapp.tests.GeographyTest)
>> AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
>> ==
>>
>>
>>
>> 4 tests are unknown failures that require further investigation. 
>> Failing testcases are:
>> ==
>> FAIL: test_difference (gis_tests.geoapp.test_functions.GISFunctionsTests)
>> ==
>> FAIL: test_difference_mixed_srid 
>> ==
>> FAIL: test_intersection 
>> (gis_tests.geoapp.test_functions.GISFunctionsTests)
>> ==
>> FAIL: test_sym_difference 
>> (gis_tests.geoapp.test_functions.GISFunctionsTests)
>> ==
>>
>> -- 
>> Jani Tiainen
>>
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/745995fb-a0c0-43f0-a5a4-2bdb8e46bc54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Oracle GIS update

[Marc Tamlyn]

Thanks for getting it running at all!

It looks to me like those tests just need to be less accurate for Oracle,
good plan.

Did you have any specific changes to make to get it to run at all? If so we
should include those soon, irrespective of whether the fixes for these
other tests make it into 1.9 final.

Marc
On 5 Nov 2015 8:21 pm, "Jani Tiainen"  wrote:

> Hi, I finally had time to get back on Oracle GIS issues.
>
> I ran test suite against 1.9.x and 7 tests fails.
>
> 3 tests are most probably due different algorithms used to calculate
> geographical distance and areas. My proposal for fix is to use backend
> spesific values.
>
> Failing testcases are:
> ==
> FAIL: test_distance_function
> (gis_tests.geogapp.tests.GeographyFunctionTests)
> AssertionError: 4899.67677194225 != 4891.2 within 2 places
> ==
> FAIL: test_geography_area (gis_tests.geogapp.tests.GeographyFunctionTests)
> AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
> ==
> FAIL: test06_geography_area (gis_tests.geogapp.tests.GeographyTest)
> AssertionError: 5439100.13586914 != 5439100.95415646 within 5 places
> ==
>
>
>
> 4 tests are unknown failures that require further investigation.
> Failing testcases are:
> ==
> FAIL: test_difference (gis_tests.geoapp.test_functions.GISFunctionsTests)
> ==
> FAIL: test_difference_mixed_srid
> ==
> FAIL: test_intersection (gis_tests.geoapp.test_functions.GISFunctionsTests)
> ==
> FAIL: test_sym_difference
> (gis_tests.geoapp.test_functions.GISFunctionsTests)
> ==
>
> --
> Jani Tiainen
>
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHn91ofJ0QQjKJ9KZXwBMLhyD59AN6sxq%3D_JtNz6xeuujH8tEw%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GS6R1zrDFaN5Xv1iF2nSj6s%3Dvc-qD1NOnXKbnhJZbEOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: add new template tag "age"

[Marc Tamlyn]

Agreed, this does not belong on core. In particular the formatting of a
duration varies widely depending on the expected age range, languages and
site context. Naturaltime is one implementation, the specific case you seem
to be hinting at is a count of years, which is definitely too particular
for Django inclusion. would make a perfect third party app though!

Mar
On 10 Nov 2015 2:57 am, "Dheerendra Rathor" 
wrote:

> If we ever need to implement age filter, I would rather suggest for
> modification of naturaltime in django.contrib.humanize to take an optional
> parameter (age = True).
>
> On Tue, 10 Nov 2015 at 01:22 Tim Graham  wrote:
>
>> For questions of whether or not to include something like this in core,
>> my own rule of thumb is, "Is this difficult to implement as a third-party
>> package? If not, do more than ~80% of sites need this feature?" If the
>> answer to both questions is "no" (which is the case here, in my opinion),
>> then I don't favor including it in Django.
>>
>> For historic reasons we have some filters like phone2numeric which likely
>> don't meet this criteria. I don't see much benefit to deprecating them, but
>> let's not add more. Other opinions welcome.
>>
>>
>> On Monday, November 9, 2015 at 2:43:46 PM UTC-5, Paulo Maciel wrote:
>>>
>>> My proposal is to add a new template tag "age": {{ birthday|age }}.
>>> I think it is a common need for many users know the age from a date.
>>>
>>>
>>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d9ce1b89-1af0-4038-816f-24e13d25a666%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAByqUgjS8nzfuwa_CApjAky-LTmADdukU9sKL3bLyh5ogA1oeA%40mail.gmail.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HHwU2d7Lngw0f4zQAt%3DOFEJmK%3DCC0TF8pXsXm2ixjobA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.