Hello, When proposing deprecations that require numerous but simple code changes, providing an automated upgrade path could reduce frustrations about "useless churn".
Unfortunately, I don't know a great way to do that on Python code. Here are the options I'm aware of: - Writing 2to3 fixers is painful, in my experience <https://github.com/django/django/commit/79d62a71751140315227891bbe175630f9d3edc3>. Also, I don't think that 2to3 will survive the deprecation of lib2to3; removal is scheduled for Python 3.12. - Bowler <https://pybowler.io/> seems designed to make it less painful, but is also written on top of lib2to3, so not a long term solution. - codemod <https://github.com/facebook/codemod> gives up fully automated refactoring (which is at odds with Python's dynamic nature) and attempts "computer-aided refactoring". - Most likely IDEs like PyCharm can rename an import throughout a project. If I had to do something in this area, I'd try codemod, probably. Of course, it will still be boring to perform the same change across N projects for no direct project-level upside, but at least it may require less time and less focus. This is relevant for the thread about renaming request.GET/POST/etc. If we proceed with that change, we're bound to have the exact same discussion about removing the original names. Best regards, -- Aymeric. > On 5 May 2020, at 17:41, Collin Anderson <cmawebs...@gmail.com> wrote: > > Hi All, > > Are we _sure_ we want to completely get rid of url()? > > Yesterday, url() was given a RemovedInDjango40Warning [PR]. The removal was > approved as part of the new path() syntax back in 2017 [DEP 0201]. > > Is this really worth it? It's only a few lines of code to keep backward > compatibility, and it seems to me it would take almost no work to maintain > that compatibility shim compared to the countless programmer hours needed to > upgrade their code, including many unpaid programmers working on open source > projects. I'll personally need to do a find/replace for url() to re_path() > across my ~20 projects, and update all of the imports. Isn't this useless > code churn? > > Yes, there's an advantage to having one and only one way to do it, so I agree > we should encourage people to use re_path() instead of url(), but shouldn't > we also make it as easy as possible to upgrade django? Is getting rid of > url() really worth the cost? > > Yes, the removal is still ~3+ years away, but that's a question of _when_ not > _if_. > > If we want, we _could_ deprecate url() without giving it an actual removal > date [Compatibility Discussion] and leave the compatibility shim around > longer, if not indefinitely. > > Thanks, > Collin > > > [PR] https://github.com/django/django/pull/12855 > > [DEP 0201] > https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst > > [Compatibility Discussion] > https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion > > -- > 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/236BB3BC-B228-4676-8955-4E302A38197F%40polytechnique.org.
