Re: Backwards-compatibility import shims

Hi All, tldr: I think we should keep django.core.urlresolvers forever, or at least much much longer. Moving things to django.core.urls makes sense; removing the one line import shim from django.core.urlresolvers doesn't make sense to me. General thoughts about compatibility, using this situati

Re: Backwards-compatibility import shims

On Wed, Dec 30, 2015 at 11:52 AM, Tim Graham wrote: > For that reason, I think we should reconsider making Django's deprecation > warnings loud by default (at least in LTS versions) [1]. Otherwise, users > will pester library authors to fix those warnings and we haven't really > made things easie

Re: Backwards-compatibility import shims

Given that alternate, I guess I'm not really enthusiastic about making our deprecation policy more complicated. While urlresolvers is a commonly used module, updating should be a simple find and replace for the imports. On the other hand, I thought of a slight flaw in our current deprecation sc

Re: Backwards-compatibility import shims

One solution is to create a RemovedInFutureVersionWarning to allow projects to catch the change when running with -Wall, without committing to a specific release. On Wednesday, December 30, 2015 at 3:05:32 PM UTC+1, Tim Graham wrote: > > To save a link click, the question is about moving > dja

Re: Backwards-compatibility import shims

To save a link click, the question is about moving django.core.urlresolvers to django.urls and whether or not to start the deprecating of django.core.urlresolvers immediately. I don't have a strong opinion myself. On one hand, delaying gives projects more time to update, on the other, I suspect

Backwards-compatibility import shims

As noted by Collin on deprecating old import paths: I personally wouldn't mind if we didn't actually deprecate this, and left > these shims in a bit longer :). (Makes it just a hair easier for people > upgrading.) But that's just