Re: Fellow Reports -- January 2019
Hi All, Calendar Week 4 -- ending 27 January. Triaged: https://code.djangoproject.com/ticket/30101 -- Recommended middleware syntax fails for some testing cases (when not using Client) (Invalid) https://code.djangoproject.com/ticket/30079 -- Prefetch cache should be aware of database source and .using() should not always trigger a new query (wontfix) https://code.djangoproject.com/ticket/30091 -- Incorrect middleware ordering allows invalid HTTP_HOST header to cause CsrfViewMiddleware failure when using CSRF_USE_SESSIONS. (Accepted) Reviewed: https://code.djangoproject.com/ticket/28905 -- Overhaul extra_requires to include more optional dependencies https://code.djangoproject.com/ticket/29973 -- compilemessages misses ignore option, compiles more than needed https://code.djangoproject.com/ticket/30111 -- AppRegistryNotReady-Error when having contrib.postgres in INSTALLED_APPS https://github.com/django/django/pull/10871 -- Fixed #30115, Refs #23748 -- Removed legacy max_length handling for CharField on SQLite. Authored: https://github.com/django/django/pull/10882 -- Fixed #30091 -- Documented middleware ordering requirements when using CSRF_USE_SESSIONS. Kind Regards, Carlton -- 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/6c3879e4-e3a7-4d60-9633-e8be54c82f1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Fellow Reports - January 2019
Week ending January 26, 2019 Triaged --- https://code.djangoproject.com/ticket/30127 - Deprecate cached_property's name argument (created) Authored -- https://github.com/django/django-formtools/pull/136 - Add testing for Django 2.2 https://github.com/brutasse/django-push/pull/26 - Add testing for Django 2.2 https://github.com/jazzband/django-hosts/pull/89 - Add testing for Django 2.2 https://github.com/jazzband/sorl-thumbnail/pull/581 - Add testing for Django 2.2 https://github.com/django/django-contrib-comments/pull/140 - Added testing for Django 2.2 and Python 3.7 https://github.com/sebleier/django-redis-cache/pull/165 - Add testing for Python 3.7 and Django 2.2 https://github.com/kennethreitz/dj-database-url/pull/115 - Add testing for Django 2.2 and Python 3.7. https://github.com/brutasse/django-password-reset/pull/76 - Add testing for Python 3.7 and Django 2.2 https://github.com/django/django/pull/10902 - Refs #30055 -- Added a helpful error when SQLite is too old. https://github.com/django/django/pull/10903 - Refs #30333 -- Doc'd change regarding apps without migrations depending on apps with migrations. Reviewed/committed -- https://github.com/django/django/pull/10850 - Corrected GenericRelation's related_query_name manual lookup example. https://github.com/django/django/pull/10861 - Fixed #30111 -- Fixed AppRegistryNotReady error with django.contrib.postgres in INSTALLED_APPS. https://github.com/django/django/pull/10857 - Fixed #30106 -- Made order_with_respect_to updates use QuerySet.bulk_update(). https://github.com/django/django/pull/10885 - Fixed #30123 -- Removed tuple support in DatabaseIntrospection.get_field_type(). -- 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/d10bc649-6cb6-4027-aabc-1676933e07b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: revisiting the Python version support policy
OK, one last email, then I'm going to bow out of this one... 🙂 I think there are two issues here: * Which versions of Python should we support? * Which version should we guide beginners to? The second of these only depends on the first because we don't support all current versions of Python in the current stable release, but only in the LTS. There was a talk at DjangoCon US. I think on f-strings but I can't quite remember, and I couldn't find the video quickly. The point is that it began by asking "Who's on v3.6 or higher?" It was about a quarter or a maybe a third of the room. That's it. The rest were on Python 3.5 (or lower). And I put it to you that we should consider the audience of "people going to DjangoCon" as likely ahead of the user base in general. (That's a priori but credible I think.) So by dropping Python 3.5 we're forcing these folks onto the LTS. I think that's sad. Django is a mature framework. That often gets talked about as if that makes it boring. But IMO it's quite the contrary. It makes it exciting. It means that for the vast majority of cases there is no need to be on the LTS. You can safely use the latest version, knowing that breaking changes will be few and easily manageable. You can have the bug fixes. You can have the new features. And the cost of that is just a day every nine-months updating. Grab a coffee, read the release notes and spend the rest of the day updating. Likely you're done by lunchtime. (If you're sensibly with your choices of third-party packages this is...) People upgrade their third-parties first, Django second, and Python last of all. (I'm always amazed by this on DRF. "I'm using EOL Django but NEED the latest DRF". This happens every time we drop a Django version.) If people are on Python 3.5 they'll stick on the LTS if that's the only version that's compatible. So we basically create a ghetto. When we could instead have a situation where being on the latest version was just the done thing. I don't think we should highlight the LTS version. I don't think we should point the docs to it by default. I don't think we should recommend that that's where users begin. I think we should build an environment where everyone™ is using the latest version, and is all the happier for it. So, again, for another (related) reason, I think we do wrong by not following Python's supported versions. (People are going to need to speak up if they agree with this though, because otherwise it won't change.) (Which is fine too: mine is just one voice.) So to the second topic: more or less asyncio. The big changes here were 3.4 to 3.5. Channels already works fine on Python 3.5. Python 3.6 introduces async generators, which sure are nice to have, but are not a deal breaker. Supporting Python 3.5 through to end of Django 3.0 is not going to make the difference to whether we can add an async view layer (or whether we being) to Django before December 2019 (when we'd drop Python 3.5). If there were a serious blocker, I'd be happy to see us being pragmatic about it. "Supporting Python version X means we can't implement important advance Y, so we're dropping that ahead of schedule." Cool. But that's really not the case here. Continuing Python 3.5 support costs us very little against the benefits to Django as a whole. Anyway, I'm spoke out here. 🙂 Have a good day all. Kind Regards, Carlton -- 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/84bcd7b9-b2c5-4ab9-bbcb-7fb42c2308d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.