Fellow Report - October 24, 2015

[Tim Graham]

On the infrastructure front, I've been working with Shai and Mariusz 
Felisiak to update the Oracle continuous integration server to Oracle 12. 
It’s mostly completed and we have some new GIS tests between Oracle 11 and 
12 to fix for anyone interested. We’ll likely retire the Oracle 11 machine 
once the transition is completed as we’re near our credit limit with 
Rackspace and can’t get it bumped up for a couple months due to a 
limitation of their billing system.

Triaged

---

https://code.djangoproject.com/ticket/25568 - Can't use template syntax 
characters within tag and filter arguments (Invalid)

https://code.djangoproject.com/ticket/25566 - Admin popup_response.html 
needs a title (accepted)

https://code.djangoproject.com/ticket/25577 - Squashed migrations do not 
work if deletion of indexed field can't be optimized on postgresql database 
(duplicate)

https://code.djangoproject.com/ticket/25570 - Using a templatetag in a 
Python file in a project template causes an Exception (wontfix)

https://code.djangoproject.com/ticket/25573 - Add simple way to use 
SplitDateTimeField on ModelForms (duplicate)

https://code.djangoproject.com/ticket/25582 - Add a way to build URLs with 
query strings (accepted)

https://code.djangoproject.com/ticket/21894 - Error in example code in 
django.forms.Form.clean() (fixed)

https://code.djangoproject.com/ticket/25564 - Django Admin's "View on Site" 
ignores model's custom manager (duplicate)

https://code.djangoproject.com/ticket/25584 - Getting Invalid syntax error 
while installing Django 1.9a1 and 1.9b1 (fixed)

https://code.djangoproject.com/ticket/25587 - Django fails, when trying to 
save object "as new" with inlines objects and form validation errors. 
(duplicate)

https://code.djangoproject.com/ticket/25579 - Lack of type adaptation in 
ArrayField querying/lookups (accepted)

https://code.djangoproject.com/ticket/25594 - Difficult to customize model 
field default_validators and have them used on both model and form fields 
(accepted)

https://code.djangoproject.com/ticket/25596 - Can't change user's password 
in admin when using custom User model (accepted)

https://code.djangoproject.com/ticket/25595 - Invalid regexp in 
URLValidator can't handle file:// schemes (accepted)

https://code.djangoproject.com/ticket/25597 - Python 3 compatibility error 
in PostgreSQL array form fields (accepted)

https://code.djangoproject.com/ticket/25601 - makemigrations create 
unnecessary migrations (invalid)

https://code.djangoproject.com/ticket/25598 - Add support for SCRIPT_NAME 
in STATIC_URL and MEDIA_URL (accepted)

https://code.djangoproject.com/ticket/25593 - Remove scheme validation from 
URLValidator or provide all IANA acceptable schemes as defaults (wontfix)

https://code.djangoproject.com/ticket/25602 - Django breaks sphinx (invalid)

Authored



https://github.com/django/django/pull/5448 - Fixed #25562 -- Skipped a time 
dependent admin_filters test on Windows.

https://github.com/django/django/pull/5461 - Fixed #25584 -- Documented a 
pip error when installing Django 1.9.

https://github.com/andialbrecht/sqlparse/pull/202 - Fix 
PendingDeprecationWarning on Python 3.5.

https://github.com/andialbrecht/sqlparse/pull/203 - Remove universal wheel

https://github.com/andialbrecht/sqlparse/pull/204 - Add Python 3.5 to 
tox/travis config.

Reviewed/committed

--

https://github.com/django/django/pull/5440 - Fixed #25565 -- Removed 
action="" from admin forms.

https://github.com/django/django/pull/5416 - Fixed #25501 -- Made the 
file-based cache backend use the highest pickling protocol.

https://github.com/django/django/pull/5445 - Fixed #25586 -- Fixed possible 
table cell misalignment in admin's tabular inlines.

https://github.com/django/django/pull/5452 - Fixed #25576 -- Added IOBase 
methods required by TextIOWrapper to HttpResponse.

https://github.com/django/django/pull/5450 - Fixed #25574 -- Documented {{ 
dict.items }} shadowing in for template tag docs.

https://github.com/django/django/pull/5403 - Fixed #24976 -- Fixed missing 
form label in tabular inline.

https://github.com/django/django/pull/5458 - Fixed #25585 -- Allowed 
setting OGRGeometry srid/srs attributes to `None`.

https://github.com/django/django/pull/5428 - Fixed #25470 -- Avoided 
unnecessary, expensive DATETIME typecast on MySQL.

https://github.com/django/django/pull/5376 - Revised Windows install 
instructions for Python 3.5.

https://github.com/django/django/pull/5462 - Fixed #25589 -- Allowed 
startapp/project to create apps with Unicode characters in the name.

https://github.com/django/django/pull/5426 - Fixed #25519 -- Made the admin 
"View site" link point to sites running on a subpath.

https://github.com/django/django/pull/5292 - Refs #24622 -- Documented 
alternatives to some test response attributes when using alternative 
template engines.

https://github.com/django/django/pull/5320 - Fixed #25434 -- Documented 
HttpRequest.site

a standard descriptor signature?

[Tim Graham]

Curtis, or should I say FunkyBob, raised the issue here: 
https://github.com/django/django/pull/5226

Currently we have several different signatures:

def __get__(self, instance, instance_type=None)
def __get__(self, obj, type=None):
def __get__(self, instance, type=None)
def __get__(self, obj, objtype)
def __get__(self, instance, owner)

and the Python docs don't seem to have a single preference.

Curtis proposed:
"""
* "instance_type" is explicit
* "cls" is a common convention for passing a class
* "owner" is in the docs {but so are others}
* and "type" I think is a bit confusing... 

So... my preference, upon reflection, would be: def __get__(self, instance, 
cls=None):
"""

For set, it's mostly: def __set__(self, instance, value)
but a couple times: def __set__(self, obj, value)

Do you think it's worth trying to be consistent or not?

-- 
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/dc073346-a9c9-4fa9-80a6-cc533346e888%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[Shai Berger]

Hi,

On Saturday 24 October 2015 04:13:47 charettes wrote:
> Hi everyone I'm the author of this change.
>  
> I submitted a PR (https://github.com/django/django/pull/5471) to completely
> revert this change given suggest adjustments don't get enough support.
> 
I don't think that's the right fix. I think a field whose default value fails 
its "clean" method is bogus and should be flagged. A warning for sure, an error 
is not insensible.

However, I'm very surprised to find out that a model field's "clean()" method 
even looks at the "blank" attribute. Like others on this thread, I was under 
the impression that it's only for model-form generation.

Shai.

Re: makemigrations --exit; exit status feels backwards from conventions

[Jon Dufresne]

Thanks everyone for the useful feedback. I've created a ticket where
the development of the idea can continue:
https://code.djangoproject.com/ticket/25604

On Fri, Oct 23, 2015 at 7:33 AM, Chris Foresman  wrote:
> Jon,
>
> You proposal seems like a sane and welcome change that aligns the exit
> status of --exit with long-standing convention.
>
>
> Thanks,
> Chris
>
>
>
> On Wednesday, October 21, 2015 at 10:20:09 AM UTC-5, Jon Dufresne wrote:
>>
>> On Tue, Oct 20, 2015 at 9:29 PM, Gavin Wahl  wrote:
>> > In your case, successfully creating a migration indicates a failure.
>>
>> Only if the --check flag is on. The --check flag indicates that one is
>> explicitly checking that all model changes have migrations. A non-zero
>> exist status indicates that migrations were missing. If you feel the
>> help text could be improved to communicate this, I can work towards
>> that.
>>
>> > Why do you object to using a ! to communicate this?
>>
>> With the --check flag or the --exit flag?
>>
>> I think I covered this in the OP. But just to clarify:
>>
>> My use case:
>>
>> Continuous integration server check's developers' commits for
>> correctness. One aspect of correctness is that all model changes have
>> migrations.
>>
>> In shell scripting and CI servers an exit status of 0 indicates
>> true/pass and an exit status of non-zero indicates false/failure.
>>
>> Therefore, the command should return 0 when everything is OK and
>> correct and non-zero otherwise. Commits are correct when all model
>> changes are accounted for.
>>
>> The current --exit behavior, returns non-zero when everything is
>> correct. To account for this in CI, one must negate the exit status
>> with !, this goes against conventional behavior.
>>
>> Further, if something goes terribly wrong and there is an unhandled
>> exception, negating the exit status will make the CI stage appear to
>> pass. This is backwards! CI can't tell the difference between "all
>> changes accounted for" and "Python had an unhandled exception".
>>
>>
>> Cheers,
>> Jon
>
> --
> 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/4a641f83-2334-4f64-b9d5-438c094dbe27%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/CADhq2b7ajz50vU_NEpwmQ8F8%3DmyVo-pKGoOkTDYbL90LrN7tYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.5 Support in Django 1.8.x?

[Tim Graham]

Here's the PR to remove 50K lines of deprecation warnings when running the 
Django 1.8 tests on Python 3.5 as well as to fix the two test failures 
caused by those warnings: https://github.com/django/django/pull/5472

In case you look and wonder about the build failures, Jenkins broke today 
after a new release of sqlparse. I submitted a fix: 
https://github.com/andialbrecht/sqlparse/pull/203

-- 
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/f13c34f1-d059-4017-8626-41d6d5c3a760%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.