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 situation an example: I think that if it's not broken, we should avoid breaking it. :) Some features are buggy or problematic or have bad api design and should be deprecated and removed. This is a simple rename so it only requires one file with one line of code (an import statement) to maintain full backwards compatibility here. Maybe we need also need a little doc stub saying that django.core.urlresolvers was renamed to django.core.urls and the new location is preferred. It seems to me when there's almost zero maintenance burden to not removing something, we shouldn't remove it, especially when it's an established and core api. We have a stable api promise[1], and we should stick to it. "If, for some reason, an API declared stable must be removed or replaced, it will be declared deprecated but will remain in the API for at least two feature releases". I don't see this as a "must" situation. There's enough changes to undocumented api's already happening that it would be great if the documented ones didn't change as much. I hard code most of my urls, so it's only 41 lines of my code across 7 projects of mine that would need to eventually get changed. Sure, it's a simple find and replace, but it's one more thing that almost every django project maintainer will need to eventually do. Or, maybe I'm the the only one who thinks we deprecate and remove things too often. I feel like I ask for backwards compatibility a lot, even though I haven't been helping out with django as much as I used to. Again, there's nothing specific about this case, there are plenty of other changes that I wish I noticed and spoke up about earlier: (assignment_tag, patterns(), django.conf.urls.defaults, generic.simple, etc). And to be clear, some deprecations (like removing allow_tags) are really, really good. :) Thanks, Collin [1] https://docs.djangoproject.com/en/dev/misc/api-stability/ On Wednesday, December 30, 2015 at 1:16:12 PM UTC-5, Michael Manfre wrote: > > > > On Wed, Dec 30, 2015 at 11:52 AM, Tim Graham <timog...@gmail.com > <javascript:>> 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 easier. >> >> Instead, the idea would be for library authors to continue using the >> deprecated APIs while supporting the LTS in which they are deprecated and >> the previous LTS. When the version of Django following the LTS is released, >> library authors can then drop support for all Django versions before the >> LTS, check their package with the LTS using python -Wall and make the >> deprecation warning fixes, then seamlessly add support for the next version >> of Django. >> >> Does that make sense? >> > > This makes sense to me. +1 > > Regards, > Michael Manfre > > -- > GPG Fingerprint: 74DE D158 BAD0 EDF8 > keybase.io/manfre > -- 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/1f054b71-45f5-467f-a672-5ede9b785075%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
