Tjena Emil, On Mon, Sep 12, 2016 at 01:32:45PM -0700, Emil Stenström wrote: > Hi Djangonauts, > > I'm just back from my second year of teaching Django to absolute beginners. > The course is a combination of HTML, CSS, Python, and Django, and after > five days of coding they have a real live website that they can show to > friends. It's always such a great experience to see the look in their eyes > when they finally understand how they can tame Django to do what they want. > > There's one big thing that keeps tripping them up is urls.py. When > specifying URL:s I get lots of questions about the regexes that they have > to specify. First: there's a strange "r" in front of each line: r"regex". > That means I will have to explain string escaping to them. Then there's the > "^" and "$" signs, both which requires explaining regular expressions at > length. Then there's [0-9]+ and finally there's the parenthesis around the > regex. All in all, looking at URLs from a beginners perspective, they are a > bunch of hieroglyphs, and very hard for beginners to grasp right away. > > I'm not suggesting that urls.py are changed for most users, I'm suggesting > that *simple_url* method (name inspired by simple_tag) is added to > django.conf.urls > that new users can use to get started quickly. This means that most > beginners can postpone learning regexes a couple of months. The exact > syntax that simple_url takes isn't important to me, as long it's a lot more > beginner friendly than what we have today: > > https://docs.djangoproject.com/en/1.10/topics/http/urls/#example > > Just to get the ideas flowing, here's a suggestion, inspired by rails > (again, exact syntax isn't important to me, simplicity to beginners is, so > feel free to suggest something else if you agree that this is an important > issue): > > from django.conf.urls import simple_url > from . import views > urlpatterns = [ > simple_url('articles/2003/', views.special_case_2003), > simple_url('articles/:year)/', views.year_archive), > simple_url('articles/:year/:month/', views.month_archive), > simple_url('articles/:year/:month/:day/', views.article_detail), > ] > > All parameters would be passed to the view as keyword parameters with the > name given and as a string, and validation would happen there instead. > > I'm thinking there should be no settings with simple_url, and that any more > advanced use-case should switch to using url instead. > > Two questions: > > A) What do you think about the prospect of simplifying urls.py for beginners?
I can certainly see where this proposal is coming from. I understand that diving into regular expressions can derail the learning process, and regular expressions are quite a heavy topic, especially when you just want to move forward through the URL routing part. On the other hand, regular expressions are a bit more flexible than what for example Flask does with is own syntax, and I'm not a big fan of having two ways of doing things. Then again, one very rarely needs the full power of regular expressions, so having something simpler by default wouldn't hurt the readability of most URL patterns. I guess I'm about +0 on this question... > B) What do you think about the specific suggestion to mimic Rails urls with a > simple_url tag? FWIW, if we choose to implement your proposal, I'm not very convinced by the Rails syntax (just based on your example). It feels like it hides too much – how does it decide on which character it will end the ":year" argument? There's no information that would make it apparent what characters will land inside the argument, and which will not. I'd be more in favor of the syntax used by Flask (or is it Werkzeug...?), where you add type information as well: ``<int:year>``. This, in my opinion, gives a better idea of what kind of characters is expected there. On the other hand, it could also lead to misunderstandings if we just turn those patterns into regular expressions, and otherwise use the same resolver machinery that we already have – the view would then still get the string extracted from the URL, not an integer as it says in the pattern. Not sure if that can be a problem or not. Cheers, Michal -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20160913073232.GR6601%40koniiiik.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
