I don't think so. Marten has been MIA unfortunately. Someone else could try to pick it up, but it seems a bit ambitious to complete in the time remaining before alpha.
On Monday, August 24, 2015 at 10:02:38 AM UTC-4, James Addison wrote: > > Hi Marten, > > I'm just curious if this is still on track for inclusion within the Sept > 21 Apha feature deadline? I've been using your Django `dispatcher_api` > branch for a new project since I learned of your proposed changes and am > excited to see them in stable Django. There hasn't been any changes in > about a month on your branch, so I'm (hopefully understandably) curious as > to its future? > > Cheers, > James > > On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote: >> >> Hi James, >> >> Thanks for taking a look at this, I really appreciate it. >> >> *Major bug:* the `request` object needs to be passed into `resolve()` >>> here: >>> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134 >>> >>> - otherwise host and scheme constraints cannot work. I believe there are >>> other instances of `resolve()` not getting `request`, but mostly in tests. >>> Is there a way for `request` to be a required parameter instead of >>> defaulting to `None`? >>> >> >> Damn... I'll fix this asap. I haven't implemented any request-based >> constraints yet, which allowed this to slip through without any test >> failures. I'm afraid I can't just make `request` a required parameter, as >> it needs to maintain backwards compatibility. With that said, the current >> function signature of `resolve()` is just... awkward. One option is to >> change it to `resolve(request_or_path, urlconf=None)`, and get the >> path_info from the request if a request is supplied. `resolve()` might >> still be called in a context where there is not request available, so I >> think we need to maintain the ability to resolve just the path. >> >> >>> *Minor bug:* Given two subdomains, my.example.com and localhost:8000, >>> going to a url using the 'localhost:8000' subdomain that only exists on >>> the 'my' subdomain (ie. http://my.example.com/test3/ exists, but you >>> try to go to http://localhost:8000/test3/), the debug mode 'patterns >>> tried list' is a series of blank lines. See image below: >>> >> >> I would've expected at least the regexes here. I'll look into this. >> >> *Nice to have:* When attempting to use multiple constraints (ie. list >>> or tuple of constraints), using `RegexPattern` seems to be required >>> when doing pattern matching - otherwise it messes up while calling >>> `construct`. First glance says this is by design? I think it would be nice >>> to still be able to use the old r'<regex here>' (without wrapping in >>> `RegexPattern`) syntax as well. Not critical, as the multi-constraints is >>> NOT breaking behaviour, just new. >>> >> >> Yes, this is more or less by design. While in the case of a single >> constraint it's nice and concise. Once you use a list of constraints you'll >> have to start counting brackets to see if that string is a RegexPattern or >> a parameter to another constraint, or you'll put each constraint on a new >> line and it doesn't matter as much imo. It isn't set in stone, so if you >> have any compelling arguments to change this, let me know. >> >> >>> *Nice to have:* I realise this isn't likely to happen at all, but it >>> would be nice if when `reverse()` and `{% url %}` are called, it would be >>> good to be able to automatically drop the scheme and host when >>> reconstituting an absolute URL if the scheme and host of the current >>> request match. However, I'm pretty sure that this is not possible, given >>> the various scenarios in which these methods can be called. Obviously, this >>> is not required, as the resulting URL (with scheme/host or without when >>> matching) will still work regardless! >>> >> >> I'll probably implement something like this before it is merged. I've >> been struggling to implement the `URL` class in a way that provided such >> methods in a way that fully conformed RFC 3986, but it was taking up too >> much of my time and I dropped it for now. I'm not sure I'll get it to >> conform to RFC 3986, but I'll surely write some basic implementation to >> output urls relative to the current host and scheme. Of course it won't >> cover 100% of the cases as the "current" host and scheme are not always >> available, but in the basic cases it should be doable. >> >> Op vrijdag 10 juli 2015 15:21:36 UTC+2 schreef Tim Graham: >>> >>> Marten, did you consider putting the new API in `django.urls` instead of >>> `django.core.urls`? I don't need there's a need to namespace it under >>> "core", but others might be able to confirm the philosophy behind this. >>> >> >> That's certainly worth considering, in fact, I quite like the idea. If >> there are no objections (philosophical or otherwise) I'll move it to >> `django.urls`. >> >> Marten >> > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/973cdeca-1809-44c2-b844-54f6f0565307%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
