Best Practices Creating a User

Hi I am a new Django user, I am working on a platform and I chose Django to develop it solely because of how "batteries included" it feels. I have to create users for my platform when they sign up, I was just wondering if its best practice to use `User` from `django.contrib.auth.models` for th

Re: Best Practices Creating a User

I think you found the wrong mailing list for this question. Might I suggest you try django-us...@googlegroups.com? The question seems better suited there. LP, Jure On 05/05/2020 14:47, 'Debjyoti Biswas' via Django developers (Contributions to Django itself) wrote: Hi I am a new Django user,

Removing url() ?

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,

Re: Removing url() ?

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 implementa

Re: Removing url() ?

... 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)" group.

Re: Removing url() ?

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 differen

Re: Removing url() ?

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 t

Re: Removing url() ?

> 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 undoubted

Getting rid of url()

Hi All, Are we ok getting rid of url()? Yesterday url() was officially slated for removal in [ticket #31534], and I know it was discussed and agreed upon back in [2017], even in a DEP, but I feel like the amount of work it would take to maintain the [shim] is near zero, and the total amount of

Re: Removing url() ?

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

I get a 404 error with “id-” in slug, I don't know if it's a bug or I'm doing something wrong.

A 404 error with “id-” in slug on multilingual website with Indonesian language in Django 3.0 More details on https://stackoverflow.com/questions/61618166/a-404-error-with-

Re: Removing url() ?

+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 discussion

Re: Removing url() ?

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() ?

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() ?

> 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: https://github.com/django/django/compare/master...collinanderson:kee

Re: Removing url() ?

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 Djang

Re: Removing url() ?

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 was

Re: I get a 404 error with “id-” in slug, I don't know if it's a bug or I'm doing something wrong.

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely t

Re: Removing url() ?

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 mov

Re: Removing url() ?

+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, I've

Re: Removing url() ?

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() ?

> 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

Rename request.GET and POST, and lowercase COOKIES, FILES, and META

request.GET and request.POST are misleadingly named: - GET contains the URL parameters and is therefore available whatever the request method. This often confuses beginners and “returners” alike. - POST contains form data on POST requests, but not other kinds of data from POST requests

Re: Removing url() ?

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 > ann

Re: GSoC 2020

Thank you both for writing proposals and contributing to the community! On Mon, 4 May 2020 at 19:14, Abhijeet Viswa wrote: > Hi guys, > > I'd like to say the same. It was a wonderful opportunity. Thanks everyone. > > Regards. > > On Mon, 4 May 2020 at 23:41, Sanskar Jaiswal > wrote: > >> Hey ev

Re: Removing url() ?

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, whi

Re: Removing url() ?

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 upgrades

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

Hmmm. I have to say I think there are areas where we could get a better ROI on our time than this. I always took the capitalisation of GET &co to come from HTTP — I'd say that's where PHP took it from too but 🤷‍♀️ That they're a bit "unpythonic" (M

Re: GSoC 2020

Yes, absolutely. Thank you both. We do hope you'll continue to be part of the community! Kind Regards, Carlton On Wednesday, 6 May 2020 00:44:03 UTC+2, Adam Johnson wrote: > > Thank you both for writing proposals and contributing to the community! > > On Mon, 4 May 2020 at 19:14, Abhijeet Vis

Re: Removing url() ?

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 import

Selected projects for Google Summer of Code 2020

Hi all. We had lots of applications for GSoC, and lots of folks to act as mentors, so I want to thank everyone there. Django was accepted into GSoC. We were granted two slots. Thus for 2020, two student proposals were selected: * Kacper Szmigiel, an undergraduate student at Technical Univers

Re: GSoC 2020

Hi, Thank you community for the guidance while I was writing my proposal. I understand that the number of slots granted for gsoc are limited. However, if the community liked my proposal, I would like to work on it. I also understand that it is difficult to provide mentors and I can write a patch