Milestoning for review. Thanks!

It may be improved a bit if support for Django 1.x gets dropped (ie: some badif will be removed).

I'm thinking this should be pushed to the 3.11 release, as that is when we'll likely drop Django 1.11

@rpkilby Good call

@rpkilby I have updated with CRUD tests and removed Django 1.11 compact. Tell me if everything is fine for you.

can you skip tests for Django 1.11 for this PR? dj1.11 seems to be supported for some more time.

I have also added an assertion inSimplePathRouter.get_urls to raise an assertion error ifpath is not defined.

Ok... seems thatpytest.mark.skipif has not worked as expected. I will recheck it as soon as I can.

Rebased.

We've not dropped 1.11 on this pass, since its LTS.

Wondering if we might just outright switch the behavior on the next release - I'd rather wedidn't have two different have two different class implementations here.

@tomchristie you are right that a single-class implementation would be better.

I think that it can be done since the difference between those two are just two methods (get_urls andget_get_lookup_*). Those methods could be guided with some initialization param in class constructor.

I will try to refactor the code to have a single class.

When we drop 1.11 I'd actually probably be okay with us justcompletely switching to.path, so long as there'ssome kind of way for users to stick with the older behavior.

There's not really any great options for us here.

@auvipy I have rebased the branch with current master. Let me know if any other change is needed.

the workflow need to be triggered

I am playing around with this PR a bit, and in my case the major reason I am trying to move topath over regular expressions is to get custom converter behaviors for the URL arguments. I have a function that transforms my model IDs as they come into and out of the API layer, and I have implemented this as a custom converter to do something like<encoded:pk> instead of<int:pk> to automatically decode the IDs before they reach any of my code.

I am able to make this work with the code in this PR by settinglookup_value_regex = "encoded" on my views. However, since I am not defining a regex here, the usage feels a little unnatural. The same behavior would apply to standard converters, likeuuid.

This isn't a blocker, since it seems to be working just fine, but figured it was worth bringing up while it is still in PR. If there is an alternative way to approach these custom converters, let me know, and I will give that a try too.

@camuthig you pointed out an interesting use case. I could change the code to use an "alternative" attribute with a more readable name to solve it, but this feels quite a mock-fix IMO.

Preserve backwards compatibility and handle this use case in an elegant way is a bit hard.

I would like to go back to my first implementation where there were 2 base router classes: one for regex and one for path, so there is no chance of mixing code and name would be quite expressive (but the project ownerclearly expressed he prefers to have a single class).

The other way I see is to rework the current implementation in order to handle the choice between regex or path on aper view basis and not globally on the router, the problem here is to handleRoute andDynamicRoute url attribute (which is currently a way orrible hack also in this implementation, since there is no guarantee that route url templates do not contains any other regex-language characters other than an initial^ and a final$).

@tomchristie what do you think would fit better?

Let us focus on the actual issue first. we are going to make the SimplRouter allowing new path based routing. should we also do the same for the DefaultRouter?

@auvipy, do you mean this line?

Apart from thatDefaultRouter should inherit fromSimpleRouter

yeah, OK. I got commit access recently. so want to prioritize this one and draw a conclusion very soon to get this merged. of course considering all the natural edge cases are ironed out

I have added a small change to address the semantic issue pointed by@camuthig.

that's great. do you see any other documentation changes needed for this?