Challenge teaching Django to beginners: urls.py
635 views
Skip to first unread message
Emil Stenström
Sep 12, 2016, 4:32:45 PM9/12/16
to Django developers (Contributions to Django itself)
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):
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 . 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?
B) What do you think about the specific suggestion to mimic Rails urls with a simple_url tag?
Thanks for reading!
Constantine Covtushenko
Sep 13, 2016, 1:20:55 AM9/13/16
to django-d...@googlegroups.com
Hi Emil,
It is a very interesting idea.
+1 from me
--
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+unsubscribe@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/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ares Ou
Sep 13, 2016, 2:26:44 AM9/13/16
to django-d...@googlegroups.com
Hi,
Actually flask uses a style very similar to what you want.
To my knowing, you must use this pattern for Django because it has the concept of including
URLs.
Routing in flask:
@app.route('post/<integer:post_id>', methods=['GET'])
def post_view(post_id=None):
# do something to render the post
return render_template('post.html', post=post)
But the problem is, you have to specify the whole URL for every view you define.
Django avoids this by separating URL patterns into different levels, that's why it uses regex to
identify the exact path. I guess it is hard for Django to organize URLs in different apps by using
such simple method.
Looking forward to more ideas!
Best regards,
Ares Ou
Software Engineer / Full-Stack Python Developer | Phone: (510) 328 - 5968
Blog: http://aresou.net | Github: https://github.com/aresowj | Stack Overflow: http://stackoverflow.com/users/5183727/ares-ou
Ares Ou
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAK52boUa_D-%2BVaf6VPgrA0YDAK4CWFbjFSWxV3RiVf-JEDXm1Q%40mail.gmail.com.
Message has been deleted
Florian Apolloner
Sep 13, 2016, 3:18:51 AM9/13/16
to Django developers (Contributions to Django itself)
Hi Emil,
There are projects like https://github.com/codysoyland/surlex which I like very much. In the end, whatever you can come up which translates to regex in the background would work just fine for django. I personally like what werkzeug does -- "stealing" that sounds like an idea too :D I do not think any core dev would be opposed to get rid of regexes by default (as long as you can still fall back to them). I personally would really like a system that works without regex on the "outside", and I'd be happy about a DEP after some further discussions here.
Cheers,
Florian
There are projects like https://github.com/codysoyland/surlex which I like very much. In the end, whatever you can come up which translates to regex in the background would work just fine for django. I personally like what werkzeug does -- "stealing" that sounds like an idea too :D I do not think any core dev would be opposed to get rid of regexes by default (as long as you can still fall back to them). I personally would really like a system that works without regex on the "outside", and I'd be happy about a DEP after some further discussions here.
Cheers,
Florian
Michal Petrucha
Sep 13, 2016, 3:33:14 AM9/13/16
to django-d...@googlegroups.com
Tjena Emil,
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
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?
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
Sjoerd Job Postmus
Sep 13, 2016, 7:13:11 AM9/13/16
to django-d...@googlegroups.com
Hi,
I don't think that the 'including' URLs part forms a problem here.
For the given example, it should be easily doable
> 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),
> ]
The following should make it possible:
import re
def simple_url(route, view, *args, **kwargs):
regex_route = re.escape(route)
regex_route = re.sub(r':([A-Za-z0-9_-]+)', r'(?P<\1>[^/]+)', regex_route)
# Anchor it to the beginning.
regex_route = '^' + regex_route
if not isinstance(view, (list, tuple)):
# It's not an include...
regex_route += '$'
return url(regex_route, view, *args, **kwargs)
(Not 100% tested, but I tested the re.sub ;) ).
So I think it is at least possible. Whether or not it's desirable though
is another question which I think I'm not suited to answer.
Kind regards,
Sjoerd Job
On Mon, Sep 12, 2016 at 11:26:36PM -0700, Ares Ou wrote:
> Hi,
>
> Actually flask uses a style very similar to what you want.
>
> To my knowing, you must use this pattern for Django because it has the
> concept of *including *
> 5968
>
> *Blog:* http://aresou.net | *Github:* https://github.com/aresowj | *Stack
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
> >> email to django-develop...@googlegroups.com.
> >> To post to this group, send email to django-d...@googlegroups.com.
> >> .
> > To post to this group, send email to django-d...@googlegroups.com.
> > Vf-JEDXm1Q%40mail.gmail.com
> > <https://groups.google.com/d/msgid/django-developers/CAK52boUa_D-%2BVaf6VPgrA0YDAK4CWFbjFSWxV3RiVf-JEDXm1Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .
> To post to this group, send email to django-d...@googlegroups.com.
I don't think that the 'including' URLs part forms a problem here.
For the given example, it should be easily doable
> 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),
> ]
import re
def simple_url(route, view, *args, **kwargs):
regex_route = re.escape(route)
regex_route = re.sub(r':([A-Za-z0-9_-]+)', r'(?P<\1>[^/]+)', regex_route)
# Anchor it to the beginning.
regex_route = '^' + regex_route
if not isinstance(view, (list, tuple)):
# It's not an include...
regex_route += '$'
return url(regex_route, view, *args, **kwargs)
(Not 100% tested, but I tested the re.sub ;) ).
So I think it is at least possible. Whether or not it's desirable though
is another question which I think I'm not suited to answer.
Kind regards,
Sjoerd Job
On Mon, Sep 12, 2016 at 11:26:36PM -0700, Ares Ou wrote:
> Hi,
>
> Actually flask uses a style very similar to what you want.
>
> To my knowing, you must use this pattern for Django because it has the
> URLs.
>
> Routing in flask:
>
> @app.route('post/<integer:post_id>', methods=['GET'])
> def post_view(post_id=None):
> # do something to render the post
> return render_template('post.html', post=post)
>
> But the problem is, you have to specify the whole URL for every view you
> define.
>
> Django avoids this by separating URL patterns into different levels, that's
> why it uses regex to
> identify the exact path. I guess it is hard for Django to organize URLs in
> different apps by using
> such simple method.
>
> Looking forward to more ideas!
>
> Best regards,
> Ares Ou
>
> *Software Engineer / Full-Stack Python Developer | **Phone:* (510) 328 -
>
> Routing in flask:
>
> @app.route('post/<integer:post_id>', methods=['GET'])
> def post_view(post_id=None):
> # do something to render the post
> return render_template('post.html', post=post)
>
> But the problem is, you have to specify the whole URL for every view you
> define.
>
> Django avoids this by separating URL patterns into different levels, that's
> why it uses regex to
> identify the exact path. I guess it is hard for Django to organize URLs in
> different apps by using
> such simple method.
>
> Looking forward to more ideas!
>
> Best regards,
> Ares Ou
>
> 5968
>
> *Blog:* http://aresou.net | *Github:* https://github.com/aresowj | *Stack
> Overflow:* http://stackoverflow.com/users/5183727/ares-ou
> >> To post to this group, send email to django-d...@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/ms
> >> gid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%
> >> 40googlegroups.com
> >> <https://groups.google.com/d/msgid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> To view this discussion on the web visit https://groups.google.com/d/ms
> >> gid/django-developers/3d002c25-9d98-49b1-b84c-55bc39c6a0f9%
> >> 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 (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to django-develop...@googlegroups.com.
> >>
> >
> > --
> > 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
> > To post to this group, send email to django-d...@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/CAK52boUa_D-%2BVaf6VPgrA0YDAK4CWFbjFSWxV3Ri
> > To view this discussion on the web visit https://groups.google.com/d/
> > Vf-JEDXm1Q%40mail.gmail.com
> > <https://groups.google.com/d/msgid/django-developers/CAK52boUa_D-%2BVaf6VPgrA0YDAK4CWFbjFSWxV3RiVf-JEDXm1Q%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 (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.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 (Contributions to Django itself)" group.
> To post to this group, send email to django-d...@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/CAFCGC%3DaX-0fvW9K%3D6dZa_wMAQVDLUAKc6mKoSzaOfCObhbmViw%40mail.gmail.com.
Message has been deleted
Anthony King
Sep 13, 2016, 7:13:11 AM9/13/16
to Django developers (Contributions to Django itself)
This is actually an interesting concept, and wouldn't incur an overheard at runtime if simple_url translated in to full regex format at launch time (or on first request, which is when the urls get loaded if I recall correctly).
I don't think this would get in the way of includes, and if it's a translator to full regex format, it can be done in a separate format.
The example from flask is interesting. What if we could define regex for our urls to have it pluggable.
simple_url.register('integer', r'[0-9]+')Ares Ou
Sep 13, 2016, 1:29:52 PM9/13/16
to django-d...@googlegroups.com
Hi,
Good to hear so much from you.
Just want know more, could anyone also explain why at first Django
chose to use regex instead of a simple URL routing, except for the flexibility?
By the way, like you said, routing in flask (or should say Werkzeug?) is also
converting the simple URLs into Regex and store it into the map.
Cheers,
Best regards,
Ares Ou
Software Engineer / Full-Stack Python Developer
On Mon, Sep 12, 2016 at 11:37 PM, Anthony King <anthon...@gmail.com> wrote:
This is actually an interesting concept, and wouldn't incur an, overheard at runtime if simple_url translated in to full regex format at launch time (or on first request, which is when the urls get loaded if I recall correctly).
I don't think this would get in the way of includes, and if it's a translator to full regex format, it can be done in a separate format.
Your example of flask's is interesting. What if we could define regex for our urls to have it pluggable.
simple_url.register('integer', r'[0-9]+')
On 13 Sep 2016 07:26, "Ares Ou" <are...@gmail.com> wrote:
Hi,Actually flask uses a style very similar to what you want.To my knowing, you must use this pattern for Django because it has the concept of includingURLs.Routing in flask:@app.route('post/<integer:post_id>', methods=['GET'])def post_view(post_id=None):# do something to render the postreturn render_template('post.html', post=post)But the problem is, you have to specify the whole URL for every view you define.Django avoids this by separating URL patterns into different levels, that's why it uses regex toidentify the exact path. I guess it is hard for Django to organize URLs in different apps by usingsuch simple method.Looking forward to more ideas!
Best regards,Ares OuSoftware Engineer / Full-Stack Python Developer | Phone: (510) 328 - 5968Blog: http://aresou.net | Github: https://github.com/aresowj | Stack Overflow: http://stackoverflow.com/users/5183727/ares-ouAres Ou
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFCGC%3DaX-0fvW9K%3D6dZa_wMAQVDLUAKc6mKoSzaOfCObhbmViw%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 (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@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/CALs0z1Zzz5YYb6OUoBxj0ShbmeHfwpiDe5ZK-A-k7XW2wA_uew%40mail.gmail.com.
Emil Stenström
Sep 13, 2016, 3:33:25 PM9/13/16
to Django developers (Contributions to Django itself)
So it looks to me that the consensus is that this IS in fact a good idea, to supply a simpler, regex-free method to define URL:s.
It also seems that the best liked version is something that's similar to what flask uses: /articles/<int:year>/<int:month>/.
I've never written a DEP before, but it sounds like a fun challenge. I'll try to look at existing DEPs for a pattern and then apply that.
Does anyone have something in particular that they would like to add to the DEP? I figure I'll try to keep this first version as simple as possible, while maintaining extension points for features that can be added later on.
It also seems that the best liked version is something that's similar to what flask uses: /articles/<int:year>/<int:month>/.
I've never written a DEP before, but it sounds like a fun challenge. I'll try to look at existing DEPs for a pattern and then apply that.
Does anyone have something in particular that they would like to add to the DEP? I figure I'll try to keep this first version as simple as possible, while maintaining extension points for features that can be added later on.
Tim Graham
Sep 13, 2016, 3:40:47 PM9/13/16
to Django developers (Contributions to Django itself)
I would like to see if this could be done as a third-party project (allow "pluggable URLs" which could use any syntax). If not, then let's accept a patch to Django to support it. Over time, if there's some strong consensus about a particular third-party package, then we could bring it in to core. I think this approach is less controversial then Django adopting some new, untested syntax right now.
Emil Stenström
Sep 13, 2016, 3:50:22 PM9/13/16
to Django developers (Contributions to Django itself)
One problem with this approach, to let the community decide on this type of feature, is the target audience of it. This is mainly a feature for beginners, and more experienced users are expected to switch over to using regexes directly to get the exact behavior they want. Beginners likely won't look at all the different options and choose one based on it's merits, they'll pick whatever their teacher suggests they use. Also installing an extra package when setting up django feels a bit strange.
So in summary, I think this COULD be done outside of Django, but that most of the benefit of this feature will come from it being part of Django. All because of the target audience.
/Emil
So in summary, I think this COULD be done outside of Django, but that most of the benefit of this feature will come from it being part of Django. All because of the target audience.
/Emil
ludovic coues
Sep 13, 2016, 3:54:49 PM9/13/16
to django-d...@googlegroups.com
There is third party module providing third party url function. Surlex
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is argument or the setting
ROOT_URLCONF as argument.
This make impossible, for exemple, to have resolver giving to the view
an int argument.
[1] http://codysoyland.com/2009/sep/6/introduction-surlex/
> To post to this group, send email to django-d...@googlegroups.com.
Cordialement, Coues Ludovic
+336 148 743 42
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is argument or the setting
ROOT_URLCONF as argument.
This make impossible, for exemple, to have resolver giving to the view
an int argument.
[1] http://codysoyland.com/2009/sep/6/introduction-surlex/
> --
> 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-develop...@googlegroups.com.
> 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
> To post to this group, send email to django-d...@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/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
> To view this discussion on the web visit
Cordialement, Coues Ludovic
+336 148 743 42
Ares Ou
Sep 13, 2016, 4:17:34 PM9/13/16
to django-d...@googlegroups.com
Emil,
Please count me in if you'd like to start a new DEP. I'm also
very interested to take this new challenge. And maybe we
should dive into the code of URL resolver part of Django before
we actually kick off?
Anyway, I myself as a experienced user also like this idea. But as
Tim and Ludovic mentioned, we might better research a bit first.
Understanding how third-party libraries implemented this kind of
simple URL could be very helpful.
Thanks.
Best regards,
Ares Ou
Software Engineer / Full-Stack Python Developer
Stack Overflow: http://stackoverflow.com/users/5183727/ares-ou
Ares Ou
> email to django-developers+unsubscribe@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/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Cordialement, Coues Ludovic
+336 148 743 42
--
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+unsubscribe@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/CAEuG%2BTa-d_RsMqj5HbspEBdKUKemfBPvjBh2%2BdJmQjU04b-V7w%40mail.gmail.com.
Florian Apolloner
Sep 14, 2016, 4:38:20 AM9/14/16
to Django developers (Contributions to Django itself)
Hi Emil,
On Tuesday, September 13, 2016 at 9:50:22 PM UTC+2, Emil Stenström wrote:
and more experienced users are expected to switch over to using regexes directly to get the exact behavior they want.
How so? Personally I would use this quite quickly since a few builtin types would cover 99%. While I can write regex in sleep nowadays, I still find it kinda tedious to redefine what "slug" means in every URL I wanna match something… I am sure others think the same.
Beginners likely won't look at all the different options and choose one based on it's merits, they'll pick whatever their teacher suggests they use. Also installing an extra package when setting up django feels a bit strange.
I think the eco system is far enough to support that, after all south lived long and well as external package. Either way, DEP or not, having an implementation out there would definitely help.
Cheers,
Florian
sjoerdjob
Sep 14, 2016, 5:02:23 AM9/14/16
to Django developers (Contributions to Django itself)
Hi all,
Since it seemed like an interesting idea to me, I started development of a third-party plugin.
It's currently at:
https://github.com/sjoerdjob/django-simple-url
Since I only started today, I have no readme/setup.py yet. Will come later this week I hope.
Current usage is
from django_simple_url import simple_url
urlpatterns = [
simple_url('hello/world/', hello_world_view),
simple_url(':year/:month/', posts_for_month_view),
]
It works proper with includes (not adding a $ to the URL), and leaf views (adding a $ to the URL).
Maybe this week, or early next week I will also add support for the '<int:year>' syntax.
Kind regards,
Sjoerd Job
Since it seemed like an interesting idea to me, I started development of a third-party plugin.
It's currently at:
https://github.com/sjoerdjob/django-simple-url
Since I only started today, I have no readme/setup.py yet. Will come later this week I hope.
Current usage is
from django_simple_url import simple_url
urlpatterns = [
simple_url('hello/world/', hello_world_view),
simple_url(':year/:month/', posts_for_month_view),
]
It works proper with includes (not adding a $ to the URL), and leaf views (adding a $ to the URL).
Maybe this week, or early next week I will also add support for the '<int:year>' syntax.
Kind regards,
Sjoerd Job
Emil Stenström
Sep 15, 2016, 2:20:03 AM9/15/16
to Django developers (Contributions to Django itself)
Great initiative!
I really think you should use the flask syntax instead of the rails one that I first suggested. Seems this is the consensus from this thread, and that makes it more likely to get it to core one day.
/Emil
I really think you should use the flask syntax instead of the rails one that I first suggested. Seems this is the consensus from this thread, and that makes it more likely to get it to core one day.
/Emil
Emil Stenström
Sep 15, 2016, 2:24:17 AM9/15/16
to Django developers (Contributions to Django itself)
See Sjoerd's code in a later reply to this thread, let's start experimenting there. /E
> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/37e44d86-696d-4b36-803a-0089232eedf9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
Cordialement, Coues Ludovic
+336 148 743 42
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
Emil Stenström
Sep 15, 2016, 2:28:07 AM9/15/16
to Django developers (Contributions to Django itself)
On Tuesday, 13 September 2016 21:54:49 UTC+2, ludovic coues wrote:
There is third party module providing third party url function. Surlex
[1] have been mentionned. But any third party solution will need to
provide function compatible with django.conf.urls.url.
Line 64 of django/urls/revolvers.py is get_resolver. This function
return a RegexURLResolver, using is argument or the setting
ROOT_URLCONF as argument.
This make impossible, for exemple, to have resolver giving to the view
an int argument.
[1] http://codysoyland.com/2009/sep/6/introduction-surlex/
I fully agree that this is a problem. If you write "/articles/<int:year>/" I think the expectation is that year will be sent in as an int, not a string. So the int serves as two different things: a validator and a typecast.
Tim Graham: Does this change your view that this should be done outside of core? Do you buy the argument that beginners are unlikely to install third party packages when learning django?
Curtis Maloney
Sep 15, 2016, 2:38:21 AM9/15/16
to django-d...@googlegroups.com, Florian Apolloner
Somewhere I have code to provide a "parse" based URL router.
Will dig it up now 1.10 has has shipped
Will dig it up now 1.10 has has shipped
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Sjoerd Job Postmus
Sep 15, 2016, 3:03:21 AM9/15/16
to Django developers (Contributions to Django itself)
Hi :).
Yes, I also added the other syntax yesterday evening, so the <int:year> syntax is now fully supported. (But it does not yield an int!!).
Currently only `'int'` is registered as a valid type, with the regex r'[0-9]+'. More can be registered using `django_simple_url.register('hex', '[0-9a-fA-F]+')`.
One downside (still) is that it does not get cast to an int. Although I'm not really sure if I find it logical that it gets cast.
I don't really have that much time to work on it, but I'm hoping to add the `setup.py` either later today or shortly after the weekend.
Kind regards,
Sjoerd Job
Yes, I also added the other syntax yesterday evening, so the <int:year> syntax is now fully supported. (But it does not yield an int!!).
Currently only `'int'` is registered as a valid type, with the regex r'[0-9]+'. More can be registered using `django_simple_url.register('hex', '[0-9a-fA-F]+')`.
One downside (still) is that it does not get cast to an int. Although I'm not really sure if I find it logical that it gets cast.
I don't really have that much time to work on it, but I'm hoping to add the `setup.py` either later today or shortly after the weekend.
Kind regards,
Sjoerd Job
Anthony King
Sep 15, 2016, 3:27:11 AM9/15/16
to django-d...@googlegroups.com
In my opinion, it should remain a string. That's the behaviour it is now, and it'll mean it can remain as a 3rd party package.
Perhaps to show it isn't being cast, it could be renamed to "integer", which would avoid confusion
--
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+unsubscribe@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/d11376c9-8a6f-45bd-940d-bc72589bf8e4%40googlegroups.com.
Sjoerd Job Postmus
Sep 15, 2016, 3:56:16 AM9/15/16
to Django developers (Contributions to Django itself)
I'm not sure if I agree.
On the one hand I would like to say:
"I agree. For instance, if the type is `hex`, it would be really weird if it were to be cast to an int. For `uuid`, would you expect a `UUID` instance, or just a string?"
but alternatively, ...
"Wouldn't it be really cool if you could specify like `<model(myapp.Blog):post>`, and it does a `get_object_or_404(myapp.Blog, post)`, and passing the actual **instance** to the view?"
Django is really great in that it has a lot of "magic" behind the scenes which allow you to write simple code. To me a good library is simple, but not too simple.
Some libraries are made in order to make complicated tasks easy.
Some libraries are made in order to make repetitive tasks less repetitive.
Some libraries do both.
For instance, the Django ORM allows you to replace complicated SQL with simple Python (although for me I still sometimes prefer the 'simplicity' of SQL ;) ).
And Django generic views allow you to have less repetitive code for writing forms and listings.
In this case, we have a potential to get rid of the
def my_sum_view(request, left_term, right_term):
left_term = int(left_term)
right_term = int(right_term)
extra_logic_here
and move all the casting to some "magic" place in a library, where it is written only once instead of many times over.
As far as naming 'int' or 'integer'... Either the library does casting or does not. I think 'int' is more obvious **once** you know Python. But 'integer' might be an *alias*, though...
Let me re-iterate: I'm not sure what will be the best approach. It really is the trade off between a simple library having a singe responsibility, or a more complex library allowing simpler code. In this case I'm somewhat considering having a bit more complex library to allow a lot more simple code.
Kind regards,
Sjoerd Job
On the one hand I would like to say:
"I agree. For instance, if the type is `hex`, it would be really weird if it were to be cast to an int. For `uuid`, would you expect a `UUID` instance, or just a string?"
but alternatively, ...
"Wouldn't it be really cool if you could specify like `<model(myapp.Blog):post>`, and it does a `get_object_or_404(myapp.Blog, post)`, and passing the actual **instance** to the view?"
Django is really great in that it has a lot of "magic" behind the scenes which allow you to write simple code. To me a good library is simple, but not too simple.
Some libraries are made in order to make complicated tasks easy.
Some libraries are made in order to make repetitive tasks less repetitive.
Some libraries do both.
For instance, the Django ORM allows you to replace complicated SQL with simple Python (although for me I still sometimes prefer the 'simplicity' of SQL ;) ).
And Django generic views allow you to have less repetitive code for writing forms and listings.
In this case, we have a potential to get rid of the
def my_sum_view(request, left_term, right_term):
left_term = int(left_term)
right_term = int(right_term)
extra_logic_here
and move all the casting to some "magic" place in a library, where it is written only once instead of many times over.
As far as naming 'int' or 'integer'... Either the library does casting or does not. I think 'int' is more obvious **once** you know Python. But 'integer' might be an *alias*, though...
Let me re-iterate: I'm not sure what will be the best approach. It really is the trade off between a simple library having a singe responsibility, or a more complex library allowing simpler code. In this case I'm somewhat considering having a bit more complex library to allow a lot more simple code.
Kind regards,
Sjoerd Job
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.
Florian Apolloner
Sep 15, 2016, 4:20:29 AM9/15/16
to Django developers (Contributions to Django itself)
On Thursday, September 15, 2016 at 8:28:07 AM UTC+2, Emil Stenström wrote:
Tim Graham: Does this change your view that this should be done outside of core? Do you buy the argument that beginners are unlikely to install third party packages when learning django?
Imo it should still stay outside of core and we should adjust the current urlresolvers to allow for such typecasts somehow. This would have the benefit of allowing other url implementations to do the same and wouldn't limit us to a single option.
Michal Petrucha
Sep 15, 2016, 4:38:09 AM9/15/16
to django-d...@googlegroups.com
On Thu, Sep 15, 2016 at 12:56:16AM -0700, Sjoerd Job Postmus wrote:
> I'm not sure if I agree.
>
> On the one hand I would like to say:
>
> "I agree. For instance, if the type is `hex`, it would be really weird if
> it were to be cast to an int. For `uuid`, would you expect a `UUID`
> instance, or just a string?"
>
> but alternatively, ...
>
> "Wouldn't it be really cool if you could specify like
> `<model(myapp.Blog):post>`, and it does a `get_object_or_404(myapp.Blog,
> post)`, and passing the actual **instance** to the view?"
As cool as this idea sounds, I really don't think the URL dispatcher
> I'm not sure if I agree.
>
> On the one hand I would like to say:
>
> "I agree. For instance, if the type is `hex`, it would be really weird if
> it were to be cast to an int. For `uuid`, would you expect a `UUID`
> instance, or just a string?"
>
> but alternatively, ...
>
> "Wouldn't it be really cool if you could specify like
> `<model(myapp.Blog):post>`, and it does a `get_object_or_404(myapp.Blog,
> post)`, and passing the actual **instance** to the view?"
is a correct component to make database queries. FWIW, I've seen
similar magic implemented in view decorators, and the thing I remember
the most from this experience was that it made it a lot harder to
follow what was happening where.
Moreover, I can imagine this turning into a complicated mess of a
syntax to allow query customizations using a weird DSL really quickly.
After all, if we allow PK lookups, it's not that unreasonable to also
want to be able to lookup by other keys, and it all goes downhill from
here.
Cheers,
Michal
Sjoerd Job Postmus
Sep 15, 2016, 4:52:46 AM9/15/16
to Django developers (Contributions to Django itself)
On Thursday, September 15, 2016 at 10:38:09 AM UTC+2, Michal Petrucha wrote:
As cool as this idea sounds, I really don't think the URL dispatcher
is a correct component to make database queries. FWIW, I've seen
similar magic implemented in view decorators, and the thing I remember
the most from this experience was that it made it a lot harder to
follow what was happening where.
Moreover, I can imagine this turning into a complicated mess of a
syntax to allow query customizations using a weird DSL really quickly.
After all, if we allow PK lookups, it's not that unreasonable to also
want to be able to lookup by other keys, and it all goes downhill from
here.
Cheers,
Michal
Agreed. It all goes downhill from there, so let's at least not do database queries.
To me, that settles it: no typecasting.
Marc Tamlyn
Sep 16, 2016, 1:49:45 AM9/16/16