Sorry for the typo. I meant to say that I think option A is more Pythonic than option B.
No problem :) I used function for possibility to support parameters filtering in future. Maybe to add macro name validation or pattern. I personally like the approach Marc suggested, which is introducing another URL resolver, rather than modifying the existing one. Very good idea too. But will it make any overhead or problems i don’t know for now, because know django core not soo deep for now. Use it as primary framework only for about 6 months. But backends and pipelines style is very good i think anyway. Moayad On 2 Jun 2014 12:36, "Alexandr Shurigin" <alexandr.shuri...@gmail.com> 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 moaya...@gmail.com Reply: django-developers@googlegroups.com django-developers@googlegroups.com Date: 2 июня 2014 г. at 13:51:53 To: django-developers@googlegroups.com django-developers@googlegroups.com 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 alexandr...@gmail.com Reply: Shurigin Alexandr alexandr...@gmail.com Date: 29 мая 2014 г. at 3:07:17 To: django-d...@googlegroups.com django-d...@googlegroups.com 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 marc....@gmail.com Reply: django-d...@googlegroups.com django-d...@googlegroups.com Date: 29 мая 2014 г. at 2:51:41 To: django-d...@googlegroups.com django-d...@googlegroups.com 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" <alexandr...@gmail.com> 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 timog...@gmail.com Reply: django-d...@googlegroups.com django-d...@googlegroups.com Date: 29 мая 2014 г. at 0:19:00 To: django-d...@googlegroups.com django-d...@googlegroups.com 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 sh...@platonix.com Reply: django-d...@googlegroups.com django-d...@googlegroups.com Date: 28 мая 2014 г. at 23:53:52 To: django-d...@googlegroups.com django-d...@googlegroups.com 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 django-develop...@googlegroups.com. To post to this group, send email to django-d...@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/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 django-develop...@googlegroups.com. To post to this group, send email to django-d...@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/83f9b1db-8585-4499-bcb7-b1fe160e8299%40googlegroups.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 django-develop...@googlegroups.com. To post to this group, send email to django-d...@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/etPan.53861b7a.79a1deaa.406%40MacBook-Pro-dude.local. 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 django-develop...@googlegroups.com. To post to this group, send email to django-d...@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/CAMwjO1EBzJ2R35PN87MZUH%2BYWkm9e_3xT-Kbd6px_6tW4qkSrA%40mail.gmail.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 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/cc342e75-05bf-416b-822a-4c2eb3bbcb80%40googlegroups.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 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/CA%2BxKnP-_TETH4odFH6-5GrZVZVNkAf2%3Dc%2BMqcBba_PAVhJBNZQ%40mail.gmail.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 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/etPan.538c4dbb.3d1b58ba.152%40MacBook-Pro-dude.local. For more options, visit https://groups.google.com/d/optout.
