Re: Removing url() ?

2020-05-10 Thread Tom Forbes
An idea for a Django equivalent to “rails generate” has been floating around my mind for quite a while. Automated codemods are not only useful for fixing deprecations but also many common, repetitive tasks that might involve modifying multiple files or boilerplate (creating a simple model,

Re: Removing url() ?

2020-05-10 Thread Bruno Alla
I've started working on a tool provides a set of codemodders for Django: https://github.com/browniebroke/django-codemod It's based on Instagram's libCST (work with Concrete

Re: Removing url() ?

2020-05-09 Thread Adam Johnson
Automated upgrade tooling would be great. Developers end up building their own anyway. One more tool we could copy is pyupgrade ( https://pypi.org/project/pyupgrade/ ). It's based upon an extension to 'tokenize' by the author (Anthony Sottile) that allows roundtripping (which I guess would be

Re: Removing url() ?

2020-05-09 Thread Aymeric Augustin
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

Re: Removing url() ?

2020-05-06 Thread Alasdair Nicol
ithout context_instance=RequestContext(request). I'm in favour of removing url() in 4.0. I think it's less likely to catch out users than render_to_response, but I do see beginners doing things like url('', ...). If we remove url() then some of that will be avoided. Hopefully we won't see

Re: Removing url() ?

2020-05-06 Thread Steven Mapes
This is the big thing for me which seems to be have been forgotten. If you need to quickly upgrade a Django project from using url to re_path the fastest way with the least amount of code changes is to simply alias the import in your urls.py files I.E ```from django.urls import re_path as

Re: Removing url() ?

2020-05-06 Thread אורי
Thank you, Carlton. אורי u...@speedy.net On Wed, May 6, 2020 at 10:06 AM Carlton Gibson wrote: > Hi Uri. > > On 6 May 2020, at 08:32, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote: > > Although I'm not sure why it was deprecated and renamed to re_path(). > > > It was part of the effort to simplify the URL

Re: Removing url() ?

2020-05-06 Thread Carlton Gibson
Hi Uri. > On 6 May 2020, at 08:32, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote: > > Although I'm not sure why it was deprecated and renamed to re_path(). It was part of the effort to simplify the URL routing, as part of Django 2.0

Re: Removing url() ?

2020-05-06 Thread אורי
Hi, Since url() is deprecated I think it should be removed. Although I'm not sure why it was deprecated and renamed to re_path(). It took me about 10 minutes to replace the calls to "url(regex=" with "re_path(route=" (I usually prefer to call all functions by parameter name) and replace the

Re: Removing url() ?

2020-05-05 Thread Kye Russell
Excuse the frankness of my reply, but I really don’t see the point in any of this. Perhaps I am not working at a scale where this becomes a legitimate issue. However I have upgraded more Django projects than I could possibly care to count, usually between LTS versions. Almost all of these

Re: Removing url() ?

2020-05-05 Thread Shai Berger
On Tue, 5 May 2020 14:18:09 -0700 James Bennett wrote: > On Tue, May 5, 2020 at 2:04 PM Shai Berger wrote: > > Why? Why is 10 years ok where 7 are not? James' points on this are > > spot on. > > > > Be that as it may, I can see sense in the request for a longer > > warned-deprecation period,

Re: Removing url() ?

2020-05-05 Thread James Bennett
On Tue, May 5, 2020 at 2:24 PM Collin Anderson wrote: > If exception/special treadment is an issue, then I'd suggest making this an > official policy change going forward. I would be much happier if all of the > examples you gave were still around with warnings. All of those upgrades were >

Re: Removing url() ?

2020-05-05 Thread Collin Anderson
> I also understand that if seven years wasn't enough time to get around to doing this, ten years also wouldn't be enough. If we postpone this to 2027 (and if Django and all of us are still around), then in 2025 or so when the deprecation warning starts being reintroduced we'll be asked for yet

Re: Removing url() ?

2020-05-05 Thread James Bennett
On Tue, May 5, 2020 at 2:04 PM Shai Berger wrote: > Why? Why is 10 years ok where 7 are not? James' points on this are spot > on. > > Be that as it may, I can see sense in the request for a longer > warned-deprecation period, which the current path does not offer. I > would be ok with introducing

Re: Removing url() ?

2020-05-05 Thread Adam Johnson
+1 for deprecating as per usual, as per all the reasons here. I'll also reply to Karen's comment: I'd be much happier with fewer tedious upgrade tasks and the ability to use > client's money for new features rather than "keeping up", sigh. > Since becoming a consultant just over a year ago,

Re: Removing url() ?

2020-05-05 Thread Tom Carrick
I'm in favour. Yes, it's some extra effort, and we have here some 30 or 40-odd projects that have either been migrated to this or will need to be in the future. But if you're hopping between LTS releases, that's another 4 years, which seems a good chunk of time for me, especially if you just

Re: Removing url() ?

2020-05-05 Thread Shai Berger
I generally sympathize with Collin's position here, but I don't think deprecation-without-intention-to-remove is a viable option. I think this discussion is analogous to the Python discussion about the removal of the ABCs from collections -- they were moved to collections.abc in 3.3, but a shim

Re: Removing url() ?

2020-05-05 Thread James Bennett
On Tue, May 5, 2020 at 1:05 PM Collin Anderson wrote:If it were 10 years from the proposal being accepted (2017 to 2027), I think that would be fine for removal then. It allows for a more natural upgrade as path() becomes more and more common. I don't see keeping url() around as slowing down

Re: Removing url() ?

2020-05-05 Thread Collin Anderson
> I don't think that we can revert [1] without a technical board approval Needing technical board approval to keep url() seems fair to me. I think most of the 2522559 changes are ok. I'd be fine if we only made these changes:

Re: Removing url() ?

2020-05-05 Thread Mariusz Felisiak
TBH, I don't see a reason to create a precedent and deprecate it without any removal plans. Deprecation and removal is described in DEP 201, I don't think that we can revert [1] without a technical board approval 樂 I would like to highlight that url() is an alias for re_path() so as far as I'm

Re: Removing url() ?

2020-05-05 Thread Karen Tracey
On Tue, May 5, 2020 at 11:42 AM Collin Anderson wrote: > Hi All, > Are we _sure_ we want to completely get rid of url()? > > I'm not! I'd be much happier with fewer tedious upgrade tasks and the ability to use client's money for new features rather than "keeping up", sigh. -- You received this

Re: Removing url() ?

2020-05-05 Thread Jon Dufresne
+1 for deprecating for eventual removal. On Tue, May 5, 2020 at 9:33 AM Mariusz Felisiak wrote: > Hi, > >I think it's worth to deprecate url() and remove it in Django 4.0 > (that's why I accepted this ticket). Aymeric proposed Django 3.1 as a > beginning of deprecation period in a

Re: Removing url() ?

2020-05-05 Thread James Bennett
On Tue, May 5, 2020 at 9:45 AM ‫אורי‬‎ wrote:‬ > My project contains about 100 calls to url() with regex. Can you explain to > me what has been changed and why, and how should I change my code to stop > using url()? And where is it documented? I checked the documentation and I > didn't find an

Re: Removing url() ?

2020-05-05 Thread Collin Anderson
> Without raising eventually-loud deprecation warnings (further along in the cycle), people who still have url() in their codebases might never even find out that the simplified DEP 201 URL routing is available. Raising a deprecation warning makes sure they find out; some projects will

Re: Removing url() ?

2020-05-05 Thread James Bennett
On Tue, May 5, 2020 at 8:42 AM Collin Anderson wrote: > 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

Re: Removing url() ?

2020-05-05 Thread אורי
My project contains about 100 calls to url() with regex. Can you explain to me what has been changed and why, and how should I change my code to stop using url()? And where is it documented? I checked the documentation and I didn't find an explanation why url() was changed and what are the

Re: Removing url() ?

2020-05-05 Thread Mariusz Felisiak
... and deprecation in Django 3.0 is defined in DEP 201 [1]. [1] https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst#imports -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Removing url() ?

2020-05-05 Thread Mariusz Felisiak
Hi, I think it's worth to deprecate url() and remove it in Django 4.0 (that's why I accepted this ticket). Aymeric proposed Django 3.1 as a beginning of deprecation period in a discussion about DEP 201 [1], it was three years ago. Moreover we removed it from the docs with the new

Removing url() ?

2020-05-05 Thread Collin Anderson
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,