date:20200505

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 everyone,
>>
>> I didn’t get selected for GSoC, but I would like to sincerely thank this
>> community for guiding me and helping me get involved in open source.
>> Especially, Simon and Carlton for solving my doubts about the ORM.
>>
>> I hope to improve myself and will definitely try again next year. I still
>> aim to work on refactoring ORM to work with ModelState.
>>
>> Thanks
>> Sanskar
>>
>> --
>> 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/CACzaa%3DEWW83WkxkSREcGowwB4ne5Qen%3DLee5iV__6hP2a%3DkqjQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Abhijeet
>
> --
> 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/CAP1-Yrq%3DY_%2BbM7cKYvhJWLtfEFoFFUknEo0txf6rgF8q5rnJ7Q%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM1dmuASPBNd72DgPKDAaZrbqfY9%2BLdqnTAA%3Di_DgwLkMQ%40mail.gmail.com.

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 
> annoying. I think an ultra-ultra-extended deprecation cycle would be a good 
> precedent. I think it makes Django more attractive as a potential platform 
> for people to build their website on. I don't see it getting in the way of 
> future evolution. Could you say more?

If you'd like Django to commit to never removing anything, and instead
to preserve every piece of documented API forever, I'm sure the DSF
will be happy to accept the generous monetary donation you no doubt
intend to make in order to assist with that task, which I assume
you'll be willing to provide on an ongoing basis for... well, forever.
An initial contribution of a few million would help to get this
rolling, and we could set up recurring billing for the future
payments.

And I'm not joking about that. Every piece of deprecated code is a
maintenance burden; it requires keeping full regression tests around
and responding to bug reports and considering the possible interaction
of every new feature that ever gets introduced. All of which comes at
a cost of time and effort and -- if it's done by the Django Fellows,
which a lot of that work is -- a cost of literal cash money out of the
DSF's pocket.

Or we could allow Django to continue shedding deprecated APIs on a
predictable and documented cycle. I really do understand that it's
annoying to put in the effort to keep up to date. I lived through
magic-removal. I've done multi-version upgrades of massive codebases
basically by myself in the past. I remember them vividly, and I know
they're not fun. And there are platforms out there which have the
kinds of "nothing is ever removed" compatibility policies you're
advocating for. But Django isn't one of them, and I don't think it
should be or, at this point in its history, can be: to work at all,
that kind of policy has to be introduced early on and has to be
allowed to influence a lot of fundamental design decisions that, in
Django's case, were already made many years ago. If we introduce such
a policy now, the very first thing i'll do is go file a DEP asking for
the old "magic" ORM to be put back, and manipulators along with it.

Anyway. As Adam mentioned, there's a good reason to put the DEP 201
URL routing in front of people's eyes in a way they'll actually
notice. Our only truly reliable tool for doing that is deprecation
backed up by the knowledge that when we deprecate something, it will
end up removed. DEP 201 set out a deprecation schedule for url(); in
hindsight I wish it were shorter and just followed the normal post-2.0
policy of one LTS-to-LTS cycle, but at this point it's too late to
change that. I'll still argue quite strongly that the deprecation
period should not be made any longer, and I'll argue with every breath
I can devote to Django that a "deprecate but never remove" policy
should not be adopted.

-- 
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/CAL13Cg8WAEBYF-TWYdCOLxknrYyLfC0tSVfHnM6xWtVWHCwyyw%40mail.gmail.com.

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. It can confuse users who are posting JSON or other
formats.

Additionally both names can lead users to think e.g. "if request.GET:"
means "if this is a GET request", which is not true.

I believe the CAPITALIZED naming style was inherited from PHP's global
variables $_GET, $_POST, $_FILES etc. (
https://www.php.net/manual/en/reserved.variables.get.php ). It stands out
as unpythonic, since these are instance variables and not module-level
constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants
).

I therefore propose these renames:

- request.GET -> request.query_params (to match Django Rest Framework -
see below)
- request.POST -> request.form_data
- request.FILES -> request.files
- request.COOKIES -> request.cookies
- request.META -> request.meta

Since these are very core attributes and the change would cause a huge
amount of churn, I propose not deprecating the old aliases immediately, but
leaving them in with a documentation note that they "may be deprecated."
Perhaps they can be like url() or ifequal which came up on the mailing list
recently - put through the normal deprecation path after a few releases
with such a note.

Django Rest Framework already aliases GET as request.query_params in its
request wrapper:
https://www.django-rest-framework.org/api-guide/requests/#query_params .
Therefore the name request.query_params should not be surprising. DRF also
provides request.data which combines request.POST and request.FILES, and
flexibly parses from different content types, but I'm not sure that's
feasible to implement in Django core.

For reference, other Python web frameworks have more "Pythonic" naming:

- Bottle: request.url_args, request.forms, request.files,
request.cookies, request.environ
- Flask: request.args, request.form, request.files, request.cookies,
request.environ
- Starlette: request.query_params, request.form(),
request.form()[field_name], request.cookies, scope

One more note for those who might think such core attributes should be left
alone: Django 2.2 added request.headers as a way of accessing headers by
name. This is convenient as it avoids the need to transform the header to
the WSGI environ name. makes the code more readable, and in the process
reduces the potential for bugs. I believe this proposal is in the same vein.

--
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/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com.

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 
another extension, and every argument being made in favor of extension in 
this thread will be as applicable on that day as it is today.

Ok fine. No 10 year end date. Please keep it forever/indefinitely.

I feel like Django keeps failing to deliver on its API stability 
promise. https://docs.djangoproject.com/en/3.0/misc/api-stability/

> All the public APIs (everything in this documentation) *will not be moved 
or renamed without providing backwards-compatible aliases*.

> If new features are added to these APIs – which is quite possible – they 
will not break or change the meaning of existing methods. In other words, 
“stable” does not (necessarily) mean “complete.”

> 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. Warnings will be issued when the deprecated method is 
called.

I don't see a good reason as to why url() "Must be removed or replaced".

> There's also no reason why url() in particular should be given special 
treatment that other deprecated features or APIs don't get. Some other 
old-time bits went far more quickly: render_to_response(), for example, got 
the standard deprecation cycle, and was removed for good in 3.0. The old 
django.core.urlresolvers module went away in 2.0. We've also long since 
gotten rid of the patterns() helper in favor of just defining URLs as a 
standard Python list. All of those were "useless code churn" -- the 
previous functions/modules worked just fine, after all. But they're all 
gone, and if you run on a supported Django version you've either dealt with 
those changes or (in the case of render_to_response()) will deal with them 
sometime in the near future.
> So again, I don't think we should make an exception here. Doing an 
ultra-ultra-extended deprecation cycle on url() beyond the current merely 
ultra-extended one would be a bad precedent for Django's future evolution, 
and I don't see any argument for it being a unique or painful enough change 
to justify such handling.

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 annoying. I think an ultra-ultra-extended deprecation cycle would be a 
good precedent. I think it makes Django more attractive as a potential 
platform for people to build their website on. I don't see it getting in 
the way of future evolution. Could you say more?

> 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 kept; it was slated to be dropped in 3.9 (up to 3.8 
there was reason to keep the shim for compatibility with 2.7), but the 
intention to execute was met with protests a lot like Collin's. The 
deprecation warnings have been loud since 3.7, but the uproar, AFAICT, only 
came with the code change in master towards 3.9.

Right, yeah I'm trying to catch this as soon as the warning is introduced, 
rather then when url() is actually removed. I feel like collections.abc is 
a much rarer thing, however, pretty much every Django project that started 
pre 2.0 uses url().


On Tuesday, May 5, 2020 at 4:39:35 PM UTC-4, James Bennett wrote:
>
> 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 Django's ability to evolve over time. 
> It makes it easier for people to upgrade, which means more projects will 
> use newer versions of django, which is a huge benefit to Django's ability 
> to evolve.
>
> I just published a kind of rant-y thing about the Python 2/3 transition, 
> so that's at the forefront of my mind. And honestly I think one lesson 
> learned there applies here too: once you get into a timeline of N years, 
> for sufficiently large N, arguments that "N years is not enough time to 
> port, but N+K years would be" simply don't hold up.
>
> I understand as well as anyone that it takes work to keep up with evolving 
> platforms, and that it can feel unrewarding to do that work -- url() 
> already exists and works, why should I have to change to calling it 
> re_path()? -- but 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

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 now the RemovedInDjango41 or even
> RemovedInDjango50 warning, and waiting a couple more releases (for
> comparison, Python usually deprecates and removes in two versions, not
> three like Django).

Not to be contrarian, but I can come right back here with "why is
removal in 5.0 OK but removal in 4.0 isn't".

Under the current removed-in-4.0 plan, people will get *six* Django
feature releases from the time re_path was introduced to the time
url() goes away. Any argument for extending it to nine is also an
argument for extending it to twelve, fifteen, eighteen, and so on. At
some point we have to decide whether we can remove things or not. I
think we can and should, and I still don't see why url() needs this
kind of special treatment when all the other deprecations we do every
LTS-to-LTS cycle don't.

-- 
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/CAL13Cg_gJ1MXRFZgMF77ciDVF5A_0P2vJbKqXafRVP6S0Zxg6w%40mail.gmail.com.

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 audited a number of
projects. I think in every one that started pre-2.0, I found bugs in regex
URL's, from missing $ signs that allow the URL to match any suffix,
match-nothing patterns, or plain wrongness. So there can be good reason to
move to path(). Of course, that's why it was added, because it's simpler
and can prevent bugs.

On Tue, 5 May 2020 at 21:27, Tom Carrick  wrote:

> 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 move
> to re_path(), which is pretty trivial, enough to be scripted. And I think
> if you upgrade at every release then you expect a bit more work to do in
> that case.
>
> I don't see a compelling enough reason to hold on to dead / undocumented
> code for close to a decade.
>
> Cheers,
> Tom
>
> --
> 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/609f55c0-d0fc-472f-9d33-dc307f8ce6e8%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM23Z8xPRwUmd2J4cLK84tQsy%2B0ptbRLcQVAp1Xv7qKigA%40mail.gmail.com.

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 move 
to re_path(), which is pretty trivial, enough to be scripted. And I think 
if you upgrade at every release then you expect a bit more work to do in 
that case.

I don't see a compelling enough reason to hold on to dead / undocumented 
code for close to a decade.

Cheers,
Tom

-- 
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/609f55c0-d0fc-472f-9d33-dc307f8ce6e8%40googlegroups.com.

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
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Tue, 5 May 2020 at 18:31, Oleg Barbos  wrote:

> 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-id-in-slug-on-multilingual-website-with-indonesian-language
>
> Is it a bug, or I'm doing something wrong?
>
> Could someone suggest a solution?
>
> --
> 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/3dda13f5-eb6e-4ee9-9054-e9ab5eabd262%40googlegroups.com
> 
> .
>

-- 
Adam

-- 
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/CAMyDDM3cs2Vcpe6Q85cn%2Bf1x5R05C2dy3jkxEB%2B_aHO2w%3DXQ0g%40mail.gmail.com.

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 was kept; it was slated to be dropped in 3.9 (up to
3.8 there was reason to keep the shim for compatibility with 2.7), but
the intention to execute was met with protests a lot like Collin's. The
deprecation warnings have been loud since 3.7, but the uproar, AFAICT,
only came with the code change in master towards 3.9.

The decision there was to delay the removal to 3.10.

On Tue, 5 May 2020 13:05:52 -0700 (PDT)
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.

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 now the RemovedInDjango41 or even
RemovedInDjango50 warning, and waiting a couple more releases (for
comparison, Python usually deprecates and removes in two versions, not
three like Django).

My 2 cents,
Shai.

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 Django's ability to evolve over time. It makes it
easier for people to upgrade, which means more projects will use newer
versions of django, which is a huge benefit to Django's ability to evolve.

I just published a kind of rant-y thing about the Python 2/3 transition, so
that's at the forefront of my mind. And honestly I think one lesson learned
there applies here too: once you get into a timeline of N years, for
sufficiently large N, arguments that "N years is not enough time to port,
but N+K years would be" simply don't hold up.

I understand as well as anyone that it takes work to keep up with evolving
platforms, and that it can feel unrewarding to do that work -- url()
already exists and works, why should I have to change to calling it
re_path()? -- but 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 another extension, and every argument being made in favor
of extension in this thread will be as applicable on that day as it is
today.

Post-2.0, Django is a lot more predictable than it used to be in terms of
API stability and compatibility. We now make stronger promises that if you
run on a Django LTS and don't have deprecation warnings, you'll be able to
run on the next LTS too (and then if you fix deprecation warnings again,
you're set for the LTS after that). That's important both for users of
Django and for the project itself: users of Django can relax a bit and
enjoy a multi-year support cycle before they have to worry about upgrading,
and the project can continue to evolve at a reasonable pace. But it only
works if we actually stick to it: if we make exceptions and start doing
longer and longer and longer deprecation cycles, the deprecation policy
won't be taken seriously.

There's also no reason why url() in particular should be given special
treatment that other deprecated features or APIs don't get. Some other
old-time bits went far more quickly: render_to_response(), for example, got
the standard deprecation cycle, and was removed for good in 3.0. The old
django.core.urlresolvers module went away in 2.0. We've also long since
gotten rid of the patterns() helper in favor of just defining URLs as a
standard Python list. All of those were "useless code churn" -- the
previous functions/modules worked just fine, after all. But they're all
gone, and if you run on a supported Django version you've either dealt with
those changes or (in the case of render_to_response()) will deal with them
sometime in the near future.

So again, I don't think we should make an exception here. Doing an
ultra-ultra-extended deprecation cycle on url() beyond the current merely
ultra-extended one would be a bad precedent for Django's future evolution,
and I don't see any argument for it being a unique or painful enough change
to justify such handling.

--
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/CAL13Cg_akYXA0-sx7%3DZ4egJ9k1uU1WgzHntscXDBu-xArPjbMA%40mail.gmail.com.

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:keepurl?expand=1


Re migration, we also need to change the imports from "django.conf.urls" to 
"django.urls". I think this is the sort of thing that changes an effortless 
django upgrade into an annoying django upgrade. Is it really worth it to 
force people to do this? Should Django be developer friendly?

> you have 4 more years to do this
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 Django's ability to evolve over time. It makes it 
easier for people to upgrade, which means more projects will use newer 
versions of django, which is a huge benefit to Django's ability to evolve.


On Tuesday, May 5, 2020 at 3:06:12 PM UTC-4, Mariusz Felisiak wrote:
>
> 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 concerned migration is really straightforward and it's not 
> time-consuming, you can use a short script to update all calls, e.g. [2], 
> and you have 4 more years to do this.
>
> Best,
> Mariusz
>
> [1] 
> https://github.com/django/django/commit/2522559d1a612a4e8885de4780ff2b7aa7b8d375
>  
> 
> [2] https://gist.github.com/felixxm/210e2a241c5ac17f5d2e569c31e1354c
>

-- 
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/19813a63-27dd-458c-93f5-769f504dfc08%40googlegroups.com.

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 
concerned migration is really straightforward and it's not time-consuming, 
you can use a short script to update all calls, e.g. [2], and you have 4 
more years to do this.

Best,
Mariusz

[1] 
https://github.com/django/django/commit/2522559d1a612a4e8885de4780ff2b7aa7b8d375
[2] https://gist.github.com/felixxm/210e2a241c5ac17f5d2e569c31e1354c

-- 
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/cd5e03a7-697f-4665-b2a8-062f1181be8e%40googlegroups.com.

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 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/CACS9raeOR7QdVHZA0ojzzu5MvdFfNw9%2B4kxuxfZ8OP93ZUbgzw%40mail.gmail.com.

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 discussion about DEP 201 [1], it was
> three years ago. Moreover we removed it from the docs with the new
> implementation [2] (also three years ago) and only versions with re_path()
> are now supported. Also, Django 3.2 is a LTS supported until April 2024 and
> it will contain url().
>
> Best,
> Mariusz
>
> [1]
> https://groups.google.com/d/msg/django-developers/D44LSp0bPg8/hKybIqNiBAAJ
> [2]
> https://github.com/django/django/commit/df41b5a05d4e00e80e73afe629072e37873e767a
>
> --
> 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/85de5898-ee51-44d8-b20b-dbe3a8865996%40googlegroups.com
> 
> .
>

-- 
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/CADhq2b71kPY%3DTCnmKNv%2BYK1mKvs7HPT%2BB6D30%3Dj3RC0s%2BE8Nog%40mail.gmail.com.

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

2020-05-05 Thread Oleg Barbos

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-id-in-slug-on-multilingual-website-with-indonesian-language

Is it a bug, or I'm doing something wrong?

Could someone suggest a solution?

-- 
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/3dda13f5-eb6e-4ee9-9054-e9ab5eabd262%40googlegroups.com.

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 explanation why url() was changed and what are the differences 
> between url() and path() and re_path()?

There is no difference; django.conf.urls.url() is just an alias for
django.urls.re_path().

-- 
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/CAL13Cg8XcXgvuXcns1nQvro-c5XcaSWvUP-khBeW%3D8Nk_Wu5fw%40mail.gmail.com.

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 programmer hours that will need to happen 
because of this change is a lot more that than. I realize it's "just" a 
project-wide find/replace from url() -> re_path(), across my ~20 projects, 
but it still seems totally useless to me. Don't we want to make upgrading 
django as easy as possible? Is getting rid of url() really worth it?

Back in 2017, the reasoning was:
"Given that it is currently used in 100% of Django projects, the smooth 
path for users would be to not deprecate django.conf.urls.url immediately, 
but to mark it as deprecated in version 3.0 (after 2.2 LTS) and remove it 
in 4.0 (after 3.2 LTS). Hopefully many projects will migrate to 
django.urls.path (the carrot) before being forced to migrate to 
django.urls.re_path (the stick)."

I haven't migrated yet, and I suppose I still have about ~3 more years to 
do it if I want to stay up to date, but that's a question of when, not if.

Again, we _could_ [deprecate without removing] if we want.

To be clear, I think the new path() was a really good improvement for 
django, and we should encourage using re_path() instead of url(), I just 
think we should maintain url() backwards-compatibility even longer, if not 
indefinitely, but maybe that's just me.

Thanks,
Collin


[ticket 
#31534] 
https://github.com/django/django/blob/f2051eb8a7febdaaa43bd33bf5a6108c5f428e59/django/conf/urls/__init__.py
[2017] 
https://groups.google.com/d/topic/django-developers/D44LSp0bPg8/discussion
[shim] https://github.com/django/django/blob/master/django/conf/urls/__init__.py
[deprecate without 
removing] 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a8aab648-34bf-4318-8361-2a1c43f33c36%40googlegroups.com.

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 undoubtedly just
find-and-replace url() to re_path(), but others will probably be happy to 
find out that the simpler path() routing exists.

Yes, I'm totally fine with raising a warning, as it brings path() to 
people's attention. I just think the url() -> re_path() migration should be 
an optional thing. People who care about code quality will see the warning 
and make the change. Those who don't care about slighty higher code quality 
will get a warning, but at least Django isn't forcing them to do something 
they don't care at all about. Their code will still run just fine on newer 
versions of Django.


On Tuesday, May 5, 2020 at 1:04:02 PM UTC-4, James Bennett wrote:
>
> 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 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? 
>
> I think it should be deprecated and removed. 
>
> On the one hand, we're talking about an extremely long (~7 years) 
> timeline from when re_path() was introduced to when it would become 
> mandatory for projects that need regex-based URL routing. That seems 
> like plenty of time for projects to notice that a new URL routing 
> approach was adopted. And that's a long, *long* time to keep 
> effectively-dead code in Django, far longer than what the normal 
> deprecation cycle would be. 
>
> On the other hand, if it doesn't get removed, it sets a bad precedent 
> -- Django needs to be able to evolve over time, and part of that is 
> ensuring that once something is no longer the recommended approach it 
> gets removed from the framework. 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 undoubtedly just 
> find-and-replace url() to re_path(), but others will probably be happy 
> to find out that the simpler path() routing exists. 
>

-- 
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/9e746ca4-97b8-4fd0-8bfb-4fa377c26b87%40googlegroups.com.

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

I think it should be deprecated and removed.

On the one hand, we're talking about an extremely long (~7 years)
timeline from when re_path() was introduced to when it would become
mandatory for projects that need regex-based URL routing. That seems
like plenty of time for projects to notice that a new URL routing
approach was adopted. And that's a long, *long* time to keep
effectively-dead code in Django, far longer than what the normal
deprecation cycle would be.

On the other hand, if it doesn't get removed, it sets a bad precedent
-- Django needs to be able to evolve over time, and part of that is
ensuring that once something is no longer the recommended approach it
gets removed from the framework. 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 undoubtedly just
find-and-replace url() to re_path(), but others will probably be happy
to find out that the simpler path() routing exists.

-- 
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/CAL13Cg-8_Bu-KKMjGrMES5YyPjXFtn22qSguP4W9H7z1mD9e2Q%40mail.gmail.com.

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
differences between url() and path() and re_path()?
אורי
u...@speedy.net


On Tue, May 5, 2020 at 6:42 PM Collin Anderson  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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/17899c17-2c07-4a80-baa5-e0a348d9512c%40googlegroups.com
> 
> .
>

-- 
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/CABD5YeF59%3DRvoSGiuM_9WkXxCFosz5d3-4rgW5eSa3aEXDeuKg%40mail.gmail.com.

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)" 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/9fa46fed-d69e-4335-b826-4d230b600faf%40googlegroups.com.

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 
implementation [2] (also three years ago) and only versions with re_path() 
are now supported. Also, Django 3.2 is a LTS supported until April 2024 and 
it will contain url().

Best,
Mariusz

[1] 
https://groups.google.com/d/msg/django-developers/D44LSp0bPg8/hKybIqNiBAAJ
[2] 
https://github.com/django/django/commit/df41b5a05d4e00e80e73afe629072e37873e767a

-- 
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/85de5898-ee51-44d8-b20b-dbe3a8865996%40googlegroups.com.

Removing url() ?