Sorry for the typo. I meant to say that I think option A is more Pythonic than option B.
I personally like the approach Marc suggested, which is introducing another URL resolver, rather than modifying the existing one. Moayad On 2 Jun 2014 12:36, "Alexandr Shurigin" <[email protected]> wrote: > Hi! Thank you for review. > > Yes i think this would be awesome feature for beginners out of the box. > > Also if add it into core, need to think a way to write ‘old-style’ clean > regex urls. Maybe via any other function or regex parameter type. I think > 1% of case somebody require this feature.For example by default urlex - > regex url pattern, url - macros url pattern. > > And about urls normalization, i think 99% people use ^ and $ in urls. This > must be by default too. What you think about it? > > About this. > > 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. > > > Maybe, but if combine regex & macro this can make some problems, because > of this i go simplest way and used colon. > > Option A is more Pythonic than option A, but I like option C better. > > There you double use option «A». I think this is a mistake. > > I think anyway minimalism is good, because django uses KIS (keep it > simple) principle. Add parameter type is good sometimes, but url doesn’t > look clean. > > As an option can review one more option - support only combined macro to > allow user enter «%(name)_%(macro type)» - :product_id, :news_slug, > :user_id, :post_slug, :post_id, etc. > > This will make urls very clean and very strong to misspells. This feature > can be managed by settings value for example named URL_MACRO_ALLOW_SHORT = > False by default. > > -- > Alexandr Shurigin > > From: Mardini Moayad [email protected] > Reply: [email protected] > [email protected] > Date: 2 июня 2014 г. at 13:51:53 > To: [email protected] [email protected] > Subject: Re: Make url patterns group kwargs more simple > > 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] >> Reply: Shurigin Alexandr [email protected] >> Date: 29 мая 2014 г. at 3:07:17 >> To: [email protected] [email protected] >> 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] >> Reply: [email protected] [email protected] >> Date: 29 мая 2014 г. at 2:51:41 >> To: [email protected] [email protected] >> 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]> 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] >>> Reply: [email protected] [email protected] >>> Date: 29 мая 2014 г. at 0:19:00 >>> To: [email protected] [email protected] >>> 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]. >>> 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/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]. >>> 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/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]. >> 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/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 > <https://groups.google.com/d/msgid/django-developers/cc342e75-05bf-416b-822a-4c2eb3bbcb80%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]. 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/CA%2BxKnP-_TETH4odFH6-5GrZVZVNkAf2%3Dc%2BMqcBba_PAVhJBNZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
