Fellow Report - October 24, 2015
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 https://github
a standard descriptor signature?
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)
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
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?
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.