Re: Review of DEP 201 - simplified routing syntax

[Chris Foresman]

Huzzah! Looking forward to the new syntax landing.


On Sunday, May 21, 2017 at 2:56:13 AM UTC-5, Aymeric Augustin wrote:
>
> Hello,
>
> The technical board accepted DEP 201: 
> https://github.com/django/deps/blob/master/accepted/0201-simplified-routing-syntax.rst
>
> Sjoerd has taken the lead on the implementation, please get in touch if 
> you'd like to help!
>
> Thanks,
>
> -- 
> Aymeric.
>
>
>
> On 12 May 2017, at 14:19, Aymeric Augustin  > wrote:
>
> After getting approval from Tom on IRC, I updated the DEP according to my 
> email below: https://github.com/django/deps/pull/41
>
> The next steps are:
>
> - account for any remaining feedback (I feel I made only minor changes 
> compared to the last version, hopefully we can wrap this up quickly now)
> - get approval from the technical board
> - complete the implementation!
>
> -- 
> Aymeric.
>
>
>
> On 12 May 2017, at 12:32, Aymeric Augustin  > wrote:
>
> Hello,
>
> I reviewed the current version of DEP 201 
> 
>  as 
> well as related 
>  
> discussions 
> .
>  
> I took notes and wrote down arguments along the way. I'm sharing them 
> below. It may be useful to add some of these arguments to the DEP.
>
> Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree 
> with the items marked *[Update DEP]* below I can prepare a PR. I will now 
> take a look at the pull requests implementing this DEP.
>
>
> *Should it live as a third-party package first?*
>
> The original motivation for this DEP was to make Django easier to use by 
> people who aren't familiar with regexes.
>
> While regexes are a powerful tool, notably for shell scripting, I find it 
> counter-productive to make them a prerequisite for building a Django 
> website. You can build a very nice and useful website with models, forms, 
> templates, and the admin, without ever needing regexes — except, until now, 
> for the URLconf!
>
> Since we aren't going to say in the official tutorial "hey install this 
> third-party package to manage your URLs", that goal can only be met by 
> building the new system into Django.
>
> Besides, I suspect many professional Django developers copy-paste regexes 
> without a deep understanding of how they work. For example, I'd be 
> surprised if everyone knew why it's wrong to match a numerical id in a URL 
> with \d+ (answer at the bottom of this email).
>
> Not only is the new system easier for beginners, but I think it'll also be 
> adopted by experienced developers to reduce the risk of mistakes in 
> URLpatterns, which are an inevitable downside of their syntax. Django can 
> solve problems like avoiding \d+ for everyone.
>
> Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
> regexes I wrote that can't be replicated with the new system are very 
> dubious and could easily be replaced with a more explicit `if 
> some_condition(request.path): raise Http404` in the corresponding view. I 
> will be happy to convert my projects to the new system.
>
> No progress was made in this area since 2008 because URL regexes are a 
> minor annoyance. After you write them, you never see them again. I think 
> that explains why no popular alternative emerged until now.
>
> Since there's a significant amount of prior art in other projects, a 
> strong consensus on DEP 201 being a good approach, and a fairly narrow 
> scope, it seems reasonable to design the new system directly into Django.
>
>
> *What alternatives would be possible?*
>
> I have some sympathy with the arguments for a pluggable URL resolver 
> system, similar to what I did for templates in Django 1.8. However I don't 
> see this happening any time soon because there's too little motivation to 
> justify the effort. As I explained above, developers tend to live with 
> whatever the framework provides.
>
> Of course, if someone wants to write a fully pluggable URL resolver, 
> that's great! But there's no momentum besides saying that "it should be 
> done that way". Furthermore, adding the new system shouldn't make it more 
> difficult to move to a fully pluggable system. If anything, it will clean 
> up the internals and prepare further work in the area. Some changes of this 
> kind were already committed.
>
> DEP 201 is mostly independent from the problem of allowing multiple views 
> to match the same URL  — 
> that is, to resume resolving URL patterns if a view applies some logic and 
> decides it can't handle a URL. This is perhaps the biggest complaint about 
> the current design of the URL resolver. Solutions include hacking around 
> the current design or changing it fundamentally.

Re: Review of DEP 201 - simplified routing syntax

[Aymeric Augustin]

Hello,

The technical board accepted DEP 201: 
https://github.com/django/deps/blob/master/accepted/0201-simplified-routing-syntax.rst
 


Sjoerd has taken the lead on the implementation, please get in touch if you'd 
like to help!

Thanks,

-- 
Aymeric.



> On 12 May 2017, at 14:19, Aymeric Augustin 
>  wrote:
> 
> After getting approval from Tom on IRC, I updated the DEP according to my 
> email below: https://github.com/django/deps/pull/41 
> 
> 
> The next steps are:
> 
> - account for any remaining feedback (I feel I made only minor changes 
> compared to the last version, hopefully we can wrap this up quickly now)
> - get approval from the technical board
> - complete the implementation!
> 
> -- 
> Aymeric.
> 
> 
> 
>> On 12 May 2017, at 12:32, Aymeric Augustin 
>> > > wrote:
>> 
>> Hello,
>> 
>> I reviewed the current version of DEP 201 
>> 
>>  as well as related 
>>  
>> discussions 
>> .
>>  I took notes and wrote down arguments along the way. I'm sharing them 
>> below. It may be useful to add some of these arguments to the DEP.
>> 
>> Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree with 
>> the items marked [Update DEP] below I can prepare a PR. I will now take a 
>> look at the pull requests implementing this DEP.
>> 
>> 
>> Should it live as a third-party package first?
>> 
>> The original motivation for this DEP was to make Django easier to use by 
>> people who aren't familiar with regexes.
>> 
>> While regexes are a powerful tool, notably for shell scripting, I find it 
>> counter-productive to make them a prerequisite for building a Django 
>> website. You can build a very nice and useful website with models, forms, 
>> templates, and the admin, without ever needing regexes — except, until now, 
>> for the URLconf!
>> 
>> Since we aren't going to say in the official tutorial "hey install this 
>> third-party package to manage your URLs", that goal can only be met by 
>> building the new system into Django.
>> 
>> Besides, I suspect many professional Django developers copy-paste regexes 
>> without a deep understanding of how they work. For example, I'd be surprised 
>> if everyone knew why it's wrong to match a numerical id in a URL with \d+ 
>> (answer at the bottom of this email).
>> 
>> Not only is the new system easier for beginners, but I think it'll also be 
>> adopted by experienced developers to reduce the risk of mistakes in 
>> URLpatterns, which are an inevitable downside of their syntax. Django can 
>> solve problems like avoiding \d+ for everyone.
>> 
>> Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
>> regexes I wrote that can't be replicated with the new system are very 
>> dubious and could easily be replaced with a more explicit `if 
>> some_condition(request.path): raise Http404` in the corresponding view. I 
>> will be happy to convert my projects to the new system.
>> 
>> No progress was made in this area since 2008 because URL regexes are a minor 
>> annoyance. After you write them, you never see them again. I think that 
>> explains why no popular alternative emerged until now.
>> 
>> Since there's a significant amount of prior art in other projects, a strong 
>> consensus on DEP 201 being a good approach, and a fairly narrow scope, it 
>> seems reasonable to design the new system directly into Django.
>> 
>> 
>> What alternatives would be possible?
>> 
>> I have some sympathy with the arguments for a pluggable URL resolver system, 
>> similar to what I did for templates in Django 1.8. However I don't see this 
>> happening any time soon because there's too little motivation to justify the 
>> effort. As I explained above, developers tend to live with whatever the 
>> framework provides.
>> 
>> Of course, if someone wants to write a fully pluggable URL resolver, that's 
>> great! But there's no momentum besides saying that "it should be done that 
>> way". Furthermore, adding the new system shouldn't make it more difficult to 
>> move to a fully pluggable system. If anything, it will clean up the 
>> internals and prepare further work in the area. Some changes of this kind 
>> were already committed.
>> 
>> DEP 201 is mostly independent from the problem of allowing multiple views to 
>> match the same URL  — 
>> that is, to resume resolving URL patterns if a view applies some logic and 
>> decides it can't handle a URL. This is perhaps the biggest complaint 

Re: Review of DEP 201 - simplified routing syntax

[Sjoerd Job Postmus]

Thinking about it some more: that is not the solution.

Also, there are probably a couple of corner cases to consider (still: the 
same as for normal regular expressions):

* What if the "keys" (named parameters) of a translated path differs from 
that of the original path?
* What if the converters differ?

For now I think the best way forward is to assume the above corner cases do 
not happen, or otherwise fall out-of-scope.

On Saturday, May 13, 2017 at 2:32:00 PM UTC+2, Sjoerd Job Postmus wrote:
>
>
>
> On Saturday, May 13, 2017 at 1:35:37 PM UTC+2, Marten Kenbeek wrote:
>>
>> The regex in `url()` can be translated 
>> 
>>  
>> using `ugettext_lazy()`, in which case the lazy translation happens when 
>> `resolve()` or `reverse()` is called. It seems the current `path()` 
>> implementation would force evaluation when the URLs are first loaded, so 
>> `resolve()` and `reverse()` would use a fixed language (whichever was 
>> active when they were loaded) rather than allowing lazy translations.
>>
>> I'm not sure how often this feature is used, but it seems like something 
>> `path()` should support out of the box. 
>>
>
> I agree. It's an oversight which I think is solvable. The 
> `LocaleRegexProvider` class already handles the caching.
>
> I will check later, but I think all that's needed is to decorate the 
> `path` function with `keep_lazy_str`. Does that seem correct to you?
>

-- 
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/37d03083-ce35-4b9d-a881-0f9c45e90db6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Marten Kenbeek]

The regex in `url()` can be translated 

 
using `ugettext_lazy()`, in which case the lazy translation happens when 
`resolve()` or `reverse()` is called. It seems the current `path()` 
implementation would force evaluation when the URLs are first loaded, so 
`resolve()` and `reverse()` would use a fixed language (whichever was 
active when they were loaded) rather than allowing lazy translations.

I'm not sure how often this feature is used, but it seems like something 
`path()` should support out of the box. 

On Friday, May 12, 2017 at 12:33:28 PM UTC+2, Aymeric Augustin wrote:
>
> Hello,
>
> I reviewed the current version of DEP 201 
> 
>  as 
> well as related 
>  
> discussions 
> .
>  
> I took notes and wrote down arguments along the way. I'm sharing them 
> below. It may be useful to add some of these arguments to the DEP.
>
> Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree 
> with the items marked *[Update DEP]* below I can prepare a PR. I will now 
> take a look at the pull requests implementing this DEP.
>
>
> *Should it live as a third-party package first?*
>
> The original motivation for this DEP was to make Django easier to use by 
> people who aren't familiar with regexes.
>
> While regexes are a powerful tool, notably for shell scripting, I find it 
> counter-productive to make them a prerequisite for building a Django 
> website. You can build a very nice and useful website with models, forms, 
> templates, and the admin, without ever needing regexes — except, until now, 
> for the URLconf!
>
> Since we aren't going to say in the official tutorial "hey install this 
> third-party package to manage your URLs", that goal can only be met by 
> building the new system into Django.
>
> Besides, I suspect many professional Django developers copy-paste regexes 
> without a deep understanding of how they work. For example, I'd be 
> surprised if everyone knew why it's wrong to match a numerical id in a URL 
> with \d+ (answer at the bottom of this email).
>
> Not only is the new system easier for beginners, but I think it'll also be 
> adopted by experienced developers to reduce the risk of mistakes in 
> URLpatterns, which are an inevitable downside of their syntax. Django can 
> solve problems like avoiding \d+ for everyone.
>
> Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
> regexes I wrote that can't be replicated with the new system are very 
> dubious and could easily be replaced with a more explicit `if 
> some_condition(request.path): raise Http404` in the corresponding view. I 
> will be happy to convert my projects to the new system.
>
> No progress was made in this area since 2008 because URL regexes are a 
> minor annoyance. After you write them, you never see them again. I think 
> that explains why no popular alternative emerged until now.
>
> Since there's a significant amount of prior art in other projects, a 
> strong consensus on DEP 201 being a good approach, and a fairly narrow 
> scope, it seems reasonable to design the new system directly into Django.
>
>
> *What alternatives would be possible?*
>
> I have some sympathy with the arguments for a pluggable URL resolver 
> system, similar to what I did for templates in Django 1.8. However I don't 
> see this happening any time soon because there's too little motivation to 
> justify the effort. As I explained above, developers tend to live with 
> whatever the framework provides.
>
> Of course, if someone wants to write a fully pluggable URL resolver, 
> that's great! But there's no momentum besides saying that "it should be 
> done that way". Furthermore, adding the new system shouldn't make it more 
> difficult to move to a fully pluggable system. If anything, it will clean 
> up the internals and prepare further work in the area. Some changes of this 
> kind were already committed.
>
> DEP 201 is mostly independent from the problem of allowing multiple views 
> to match the same URL  — 
> that is, to resume resolving URL patterns if a view applies some logic and 
> decides it can't handle a URL. This is perhaps the biggest complaint about 
> the current design of the URL resolver. Solutions include hacking around 
> the current design or changing it fundamentally.
>
> This proposal doesn't change anything to the possibility of autogenerating 
> URL structures, like DRF's routers do.
>
> I'm aware of one realistic proposals for a more elaborate and perhaps 
> cleaner system: Marten Kenbeek's dispatcher API refactor at: 
> 

Re: Review of DEP 201 - simplified routing syntax

[Aymeric Augustin]

> On 12 May 2017, at 19:05, Marten Kenbeek  wrote:
> 
> That's not quite right. Django has actually been using the `re.UNICODE` flag 
> since at least 1.0, so you'd have the same problem on Python 2. 

Since 1.0 exactly; this behavior was introduced in 
https://github.com/django/django/commit/8c85ddf306e6d707e4bd521e7708509a3fb29bf1
 
.

Since it was hardly noticed in a decade, it can't be too much of a problem in 
practice...

-- 
Aymeric.

-- 
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/E46EABDB-1BEE-407C-91DD-347506DE037D%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Marten Kenbeek]

On Friday, May 12, 2017 at 6:43:34 PM UTC+2, Florian Apolloner wrote:
>
>
>
> On Friday, May 12, 2017 at 12:33:28 PM UTC+2, Aymeric Augustin wrote:
>>
>> Django's URL resolver matches URLs as str (Unicode strings), not bytes, 
>> after percent and UTF-8 decoding. As a consequence \d matches any 
>> character in Unicode character category Nd 
>> , for 
>> example, ١ which is 1 in Arabic (unless you also specified the ASCII flag 
>> on the regex)
>>
>
> Ha, I was thinking that you might get somewhere along the lines of this. 
> That only became an issue with python 3 right? Before regex defaulted to 
> re.ASCII.
>  
>

That's not quite right. Django has actually been using the `re.UNICODE` 
flag since at least 1.0, so you'd have the same problem on Python 2. 

-- 
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/d2e6048a-3fbd-43f0-8059-fa77a1c6bc7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Florian Apolloner]

On Friday, May 12, 2017 at 12:33:28 PM UTC+2, Aymeric Augustin wrote:
>
> Django's URL resolver matches URLs as str (Unicode strings), not bytes, 
> after percent and UTF-8 decoding. As a consequence \d matches any 
> character in Unicode character category Nd 
> , for 
> example, ١ which is 1 in Arabic (unless you also specified the ASCII flag 
> on the regex)
>

Ha, I was thinking that you might get somewhere along the lines of this. 
That only became an issue with python 3 right? Before regex defaulted to 
re.ASCII.
 

-- 
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/214cf377-d740-4d82-bee8-a1c200a82a7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Review of DEP 201 - simplified routing syntax

[Aymeric Augustin]

After getting approval from Tom on IRC, I updated the DEP according to my email 
below: https://github.com/django/deps/pull/41 


The next steps are:

- account for any remaining feedback (I feel I made only minor changes compared 
to the last version, hopefully we can wrap this up quickly now)
- get approval from the technical board
- complete the implementation!

-- 
Aymeric.



> On 12 May 2017, at 12:32, Aymeric Augustin 
>  wrote:
> 
> Hello,
> 
> I reviewed the current version of DEP 201 
> 
>  as well as related 
>  
> discussions 
> .
>  I took notes and wrote down arguments along the way. I'm sharing them below. 
> It may be useful to add some of these arguments to the DEP.
> 
> Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree with 
> the items marked [Update DEP] below I can prepare a PR. I will now take a 
> look at the pull requests implementing this DEP.
> 
> 
> Should it live as a third-party package first?
> 
> The original motivation for this DEP was to make Django easier to use by 
> people who aren't familiar with regexes.
> 
> While regexes are a powerful tool, notably for shell scripting, I find it 
> counter-productive to make them a prerequisite for building a Django website. 
> You can build a very nice and useful website with models, forms, templates, 
> and the admin, without ever needing regexes — except, until now, for the 
> URLconf!
> 
> Since we aren't going to say in the official tutorial "hey install this 
> third-party package to manage your URLs", that goal can only be met by 
> building the new system into Django.
> 
> Besides, I suspect many professional Django developers copy-paste regexes 
> without a deep understanding of how they work. For example, I'd be surprised 
> if everyone knew why it's wrong to match a numerical id in a URL with \d+ 
> (answer at the bottom of this email).
> 
> Not only is the new system easier for beginners, but I think it'll also be 
> adopted by experienced developers to reduce the risk of mistakes in 
> URLpatterns, which are an inevitable downside of their syntax. Django can 
> solve problems like avoiding \d+ for everyone.
> 
> Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
> regexes I wrote that can't be replicated with the new system are very dubious 
> and could easily be replaced with a more explicit `if 
> some_condition(request.path): raise Http404` in the corresponding view. I 
> will be happy to convert my projects to the new system.
> 
> No progress was made in this area since 2008 because URL regexes are a minor 
> annoyance. After you write them, you never see them again. I think that 
> explains why no popular alternative emerged until now.
> 
> Since there's a significant amount of prior art in other projects, a strong 
> consensus on DEP 201 being a good approach, and a fairly narrow scope, it 
> seems reasonable to design the new system directly into Django.
> 
> 
> What alternatives would be possible?
> 
> I have some sympathy with the arguments for a pluggable URL resolver system, 
> similar to what I did for templates in Django 1.8. However I don't see this 
> happening any time soon because there's too little motivation to justify the 
> effort. As I explained above, developers tend to live with whatever the 
> framework provides.
> 
> Of course, if someone wants to write a fully pluggable URL resolver, that's 
> great! But there's no momentum besides saying that "it should be done that 
> way". Furthermore, adding the new system shouldn't make it more difficult to 
> move to a fully pluggable system. If anything, it will clean up the internals 
> and prepare further work in the area. Some changes of this kind were already 
> committed.
> 
> DEP 201 is mostly independent from the problem of allowing multiple views to 
> match the same URL  — 
> that is, to resume resolving URL patterns if a view applies some logic and 
> decides it can't handle a URL. This is perhaps the biggest complaint about 
> the current design of the URL resolver. Solutions include hacking around the 
> current design or changing it fundamentally.
> 
> This proposal doesn't change anything to the possibility of autogenerating 
> URL structures, like DRF's routers do.
> 
> I'm aware of one realistic proposals for a more elaborate and perhaps cleaner 
> system: Marten Kenbeek's dispatcher API refactor at: 
> https://github.com/knbk/django/tree/dispatcher_api 
> . I can't say if the 
> implementation of DEP 201 will break that effort. Anyway we can't 

Review of DEP 201 - simplified routing syntax

[Aymeric Augustin]

Hello,

I reviewed the current version of DEP 201 

 as well as related 
 
discussions 
.
 I took notes and wrote down arguments along the way. I'm sharing them below. 
It may be useful to add some of these arguments to the DEP.

Sjoerd, Tom, I didn't want to edit your DEP directly, but if you agree with the 
items marked [Update DEP] below I can prepare a PR. I will now take a look at 
the pull requests implementing this DEP.


Should it live as a third-party package first?

The original motivation for this DEP was to make Django easier to use by people 
who aren't familiar with regexes.

While regexes are a powerful tool, notably for shell scripting, I find it 
counter-productive to make them a prerequisite for building a Django website. 
You can build a very nice and useful website with models, forms, templates, and 
the admin, without ever needing regexes — except, until now, for the URLconf!

Since we aren't going to say in the official tutorial "hey install this 
third-party package to manage your URLs", that goal can only be met by building 
the new system into Django.

Besides, I suspect many professional Django developers copy-paste regexes 
without a deep understanding of how they work. For example, I'd be surprised if 
everyone knew why it's wrong to match a numerical id in a URL with \d+ (answer 
at the bottom of this email).

Not only is the new system easier for beginners, but I think it'll also be 
adopted by experienced developers to reduce the risk of mistakes in 
URLpatterns, which are an inevitable downside of their syntax. Django can solve 
problems like avoiding \d+ for everyone.

Anecdote: I keep making hard-to-detect errors in URL regexes. The only URL 
regexes I wrote that can't be replicated with the new system are very dubious 
and could easily be replaced with a more explicit `if 
some_condition(request.path): raise Http404` in the corresponding view. I will 
be happy to convert my projects to the new system.

No progress was made in this area since 2008 because URL regexes are a minor 
annoyance. After you write them, you never see them again. I think that 
explains why no popular alternative emerged until now.

Since there's a significant amount of prior art in other projects, a strong 
consensus on DEP 201 being a good approach, and a fairly narrow scope, it seems 
reasonable to design the new system directly into Django.


What alternatives would be possible?

I have some sympathy with the arguments for a pluggable URL resolver system, 
similar to what I did for templates in Django 1.8. However I don't see this 
happening any time soon because there's too little motivation to justify the 
effort. As I explained above, developers tend to live with whatever the 
framework provides.

Of course, if someone wants to write a fully pluggable URL resolver, that's 
great! But there's no momentum besides saying that "it should be done that 
way". Furthermore, adding the new system shouldn't make it more difficult to 
move to a fully pluggable system. If anything, it will clean up the internals 
and prepare further work in the area. Some changes of this kind were already 
committed.

DEP 201 is mostly independent from the problem of allowing multiple views to 
match the same URL  — that 
is, to resume resolving URL patterns if a view applies some logic and decides 
it can't handle a URL. This is perhaps the biggest complaint about the current 
design of the URL resolver. Solutions include hacking around the current design 
or changing it fundamentally.

This proposal doesn't change anything to the possibility of autogenerating URL 
structures, like DRF's routers do.

I'm aware of one realistic proposals for a more elaborate and perhaps cleaner 
system: Marten Kenbeek's dispatcher API refactor at: 
https://github.com/knbk/django/tree/dispatcher_api 
. I can't say if the 
implementation of DEP 201 will break that effort. Anyway we can't wait forever 
on a branch that has no schedule for completion.

To sum up, I don't see any bigger improvement that is likely to be implemented 
in the short run and would justify delaying DEP 201.


Which types should be supported?

Integers, slugs, UUIDs and arbitrary strings will cover the vast majority of 
cases. I haven't seen any other examples in all discussions.

I don't think it's reasonable to include floats in URLs. Reversing a URL could 
lead to atrocities such as /foo/0.34/bar/. This doesn't look 
good.

I don't think the use case is sufficiently common to add supports for Decimal, 
which wouldn't suffer from that issue.

So I would remove float and add slug.