Hi Alexandr, Thanks for the nice suggestion. It's good to try to improve Django in an area you think it might be lacking.
I also think this is a really nice feature to add to the framework, which will make it more beginner-friendly. I'll try to discuss what I think is the most important features that should be considered in a potential new resolver that might be added to the core. There are currently many options to start with, including: *Surlex*: https://github.com/codysoyland/surlex *hurl*: https://github.com/oinopion/hurl *smarturls*: https://github.com/amitu/smarturls/ *Django Macros Url*: https://github.com/phpdude/django-macros-url/ *Regex Builder*: https://github.com/bruntonspall/regex-builder The features include: *1) The syntax of the new URL:* Since the whole point of introducing another URL resolver is to make the syntax simpler, I think this is the most important feature. The options are: A) The colon syntax: url('news/:year/:month/:day$', 'news_view') B) An angle brackets tag syntax: surl('news/<year>/<month>/<day>', ' news_view') C) A chain of function calls: str(repeats(literal('a'),2,3)) IMHO, option C is too ugly, but option B is the most natural for a beginner to use, especially when used with a named group, see point 2. *2) How expressive the patterns names are:* A) Expressive, reflects what the real regex will be: <int4:birth_year> B) The predefined pattern uses a simple name : <year:birth_year> C) Minimalist, where the name of the predefined pattern will be automatically be used as a named group: <year> (I'm not sure if this approach is used by any library or whether it's a good one, I just though of it and added it for completeness.) *3) Extending the predefined patterns:* A) Using a dictionary: h.matchers['year'] = r'\d{4}' B) Using a function call: macrosurl.register('myhash', '[a-f0-9]{9}') C) Using a setting in settings.py: SURL_REGEXERS = { ... } Option A is more Pythonic than option A, but I like option C better. Thanks. On Saturday, May 31, 2014 10:44:33 PM UTC+3, Alexandr Shurigin wrote: > > hi all. > > I developed first version of application, you can take a look into it. > > https://github.com/phpdude/django-macros-url/ > > You can take a look into tests to see for really big url patterns :)) > > Library is simple as possible and makes a lot of extra work. > > I think some type of library must be in core, what you think? > > Thanks > > -- > Alexandr Shurigin > > From: Shurigin Alexandr [email protected] <javascript:> > Reply: Shurigin Alexandr [email protected] <javascript:> > Date: 29 мая 2014 г. at 3:07:17 > To: [email protected] <javascript:> > [email protected] <javascript:> > Subject: Re: Make url patterns group kwargs more simple > > happy Urls doesn’t look simpler, just splitter configuration to parts .. > This doesn’t make urls more readable i think. Sometimes this way is good, > but not always. > > > -- > Alexandr Shurigin > > From: Tamlyn Marc [email protected] <javascript:> > Reply: [email protected] <javascript:> > [email protected] <javascript:> > Date: 29 мая 2014 г. at 2:51:41 > To: [email protected] <javascript:> > [email protected] <javascript:> > Subject: Re: Make url patterns group kwargs more simple > > I'm in favour of introducing another URL resolver, as a simpler option > not as a replacement. My motivation is not "because it's nicer", rather to > lower the boundary to entry. The Regex syntax is difficult for beginners. > > There are many competing options, those mentioned and also hurl ( > github.com/oinopion/hurl). There are probably more around. > > At the moment, I'm unsure about which format is preferable, and I'd be > more interested to see changes to Django to make it easier to change the > URL resolving system, including reversal. Having a standards API documented > which allows patterns/URL/resolve to be intermingled with analogues with > different rules is a good idea. It's not quite a 'urlbackend' as I'd like > different ones to work in the same project, but that's the idea. This would > also make handling complex URL resolving concepts easier to do outside of > Django (e.g. a ContinueResolving exception views can raise to try later > patterns) > > I'm not saying any of this is not currently possible - it is. But I'd > prefer to introduce a stable, robust API and then look at exact > implementations of format. > > Marc > On 28 May 2014 18:23, "Alexandr Shurigin" <[email protected] > <javascript:>> wrote: > >> surlex library looks little bit simpler then smarturls. >> >> http://amitu.com/smarturls/ >> >> surl('/year/<int4:year>/', 'year.view'), >> surl('/year/<int4:year>/<word:month>/', 'month.view’), >> >> And surlex example >> >> >> /articles/<year:Y>/<slug:s>/(<page:#>/) >> >> Surlex looks more user-friendly. >> >> I think need to have a look for such libraries, make choose about patterns >> formatting and implement this right way into django. >> >> Ruby rails way looks simplest of this two. Also we can check ror routing >> patterns and make choose. >> >> What you think? >> >> alex. >> >> -- >> Alexandr Shurigin >> >> From: Graham Tim [email protected] <javascript:> >> Reply: [email protected] <javascript:> >> [email protected] <javascript:> >> Date: 29 мая 2014 г. at 0:19:00 >> To: [email protected] <javascript:> >> [email protected] <javascript:> >> Subject: Re: Make url patterns group kwargs more simple >> >> There was also a mention in IRC by a core dev (Jannis, I think) about >> the possibility of merging http://amitu.com/smarturls/ into core. I >> agree URL regexes is something that we could improve, but as there are many >> solutions out there, this would require discussion and a consensus. >> >> On Wednesday, May 28, 2014 1:05:29 PM UTC-4, Alexandr Shurigin wrote: >>> >>> Thank you for your answer. >>> >>> yes, that’ is not big problem in coding this feature locally or in >>> django core. i just wanted to show interesting feature for django users. >>> This feature can help new users with urls patterning and make existing code >>> more readable. >>> >>> Yes i will make component for django with supporting this feature and >>> will try to publish it anywhere available to community. Maybe people will >>> like it :) >>> >>> For me this feature looks very usable. >>> >>> Sorry for my english. Not native language. >>> >>> -- >>> Alexandr Shurigin >>> >>> From: Berger Shai [email protected] >>> Reply: [email protected] [email protected] >>> Date: 28 мая 2014 г. at 23:53:52 >>> To: [email protected] [email protected] >>> Subject: Re: Make url patterns group kwargs more simple >>> >>> Hi Alexendr, >>> >>> On Wednesday 28 May 2014 18:54:05 Alexandr Shurigin wrote: >>> > Hi all. >>> > >>> > What do you think about adding some extra default and more simpler >>> syntax >>> > for url patterns? >>> > >>> [looking for a way to re-write...] >>> > >>> > >>> url(r'^(?P<slug_genre>[^/]+)/(?P<slug>[^/]+)/news/(?P<slug_item>[^/]+)$',... >>> > >>> [...as...] >>> > >>> > >>> > url(r'^:slug_genre/:slug/news/:slug_item$', ,,, >>> > >>> > This will make urls very short, fast-readable and writable. >>> > >>> I agree -- but there are two points: >>> >>> 1) The kind of expressions you'd want to use is probably very >>> project-specific; >>> >>> 2) Something very close is easy to achieve, without any change to >>> Django. For >>> example, for the case you gave above, add this near the top of your >>> urls.py: >>> >>> import re >>> def t(tag_url): >>> """ >>> Take a URL pattern with parts marked as :tag, and return >>> the appropriate Django url-pattern >>> """ >>> tag = re.compile(r':([\w]+)') >>> pat, _ = tag.subn(r'(?P<\1>[^/]+)', tag_url) >>> return pat >>> >>> and now, you can write your urls as >>> >>> url(t(r'^:slug_genre/:slug/news/:slug_item$'), ,,, >>> >>> or even add further: >>> >>> def turl(pat, *args, **kw): return url(t(pat), *args, **kw) >>> >>> and write urls as >>> >>> turl(r'^:slug_genre/:slug/news/:slug_item$', ,,, >>> >>> Thus, I'm not sure anything needs to be changed in Django to support >>> this. >>> >>> You can, of course, make some generalization of this and offer it to the >>> community -- if it becomes very popular, it then may be a good candidate >>> for >>> inclusion in Django. Just to be clear, I'm *not* saying that it won't be >>> -- >>> just that, before adding something like this to Django, we'd want to see >>> how >>> it gets used, so the feature we finally implement is useful for many >>> people. >>> >>> HTH, >>> Shai. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> 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/201405281953.35201.shai%40platonix.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/83f9b1db-8585-4499-bcb7-b1fe160e8299%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/83f9b1db-8585-4499-bcb7-b1fe160e8299%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/etPan.53861b7a.79a1deaa.406%40MacBook-Pro-dude.local >> >> <https://groups.google.com/d/msgid/django-developers/etPan.53861b7a.79a1deaa.406%40MacBook-Pro-dude.local?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > 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/CAMwjO1EBzJ2R35PN87MZUH%2BYWkm9e_3xT-Kbd6px_6tW4qkSrA%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAMwjO1EBzJ2R35PN87MZUH%2BYWkm9e_3xT-Kbd6px_6tW4qkSrA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/cc342e75-05bf-416b-822a-4c2eb3bbcb80%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
