Re: DEP pre-proposal for a simpler URLs syntax.

[Ola Sitarska]

I'm quite excited about this: it's definitely gonna solve some of the pain
points we're facing when teaching Django to Django Girls! Big +1 to include
it in core.

I recently started dabbling a bit in Rails, and wondered if it'd be
possible here to get rid of the converter in the syntax at all, or have a
default one if none is provided. For complete beginners, even figuring out
what's this `int` or `string` is again is another thing they have to think
of, and it might be beneficial to think of the really really really simple
way. Here is how Rails do it
,
and I was quite surprised how easy that is. Haven't looked into any
implementation details of current urls or new simple urls, so this idea
might be a completely wrong one, I admit :)

Good job, I'm really happy see this being worked on!

Cheers,
Ola





On Wed, Oct 5, 2016 at 9:24 PM, Robert Roskam 
wrote:

> Hey All,
>
> Sorry all. I accidentally submitted my message somehow.
>
> I wanted to say that I like the direction Django is going compared to the
> other Python frameworks for its routing. I've looked at Express.js,
> angularjs, rails, and MVC.NET as well. And Django is definitely the
> easiest to read among them.
>
> I think this syntax offers both simplicity in not missing dumb stuff like
> the leading ^ and the trailing $, but it also lets us work toward more
> expressive routing patterns in the future.
>
> Robert Roskam
>
>
> On Wednesday, October 5, 2016 at 4:08:08 PM UTC-4, Robert Roskam wrote:
>>
>> Hey Tom,
>>
>> I really like your current implementation. I think it's an elegant
>> solution to a complex problem, and I like that you looked at Flask for some
>> inspiration.
>>
>> I thought that to round out the discussion I'd do a quick comparison to
>> other frameworks. (I've added in slug examples):
>>
>> *Django*
>>
>> urlpatterns = [
>> url(r'^articles/2003/$', views.special_case_2003),
>> url(r'^articles/(?P[0-9]{4})/$', views.year_archive),
>> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/$', 
>> views.month_archive),
>> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/(?P[0-9]{2})/$', 
>> views.article_detail),url(r'^articles/(?P[\w-]+)/$', 
>> views.slug_view),
>> ]
>>
>>
>>
>> *DEP*
>>
>> urlpatterns = [
>> path('articles/2003/', views.special_case_2003),
>> path('articles//', views.year_archive),
>> path('articles///', views.month_archive),
>> path('articles', 
>> views.article_detail),path('articles//', views.slug_view),
>> ]
>>
>>
>>
>>
>>
>> *Flask*
>> Doesn't really have the idea of putting all your routes in one spot. So
>> pardon the silly example.
>>
>>
>> @app.route('articles/2003/')
>> def special_case_2003():
>>  pass
>>
>> @app.route('articles//')
>> def year_archive(year):
>>  pass
>>
>> @app.route('articles///')
>> def month_archive(year, month):
>>  pass
>>
>> @app.route('articles')
>> def article_detail(year, month, day):
>>  pass
>>
>> @app.route('articles//')
>> def slug_view(slug):
>>  pass
>>
>>
>>
>>
>> *Bottle*
>> It's basically Flask (big surprise).
>>
>> @route('articles/2003/')
>> def special_case_2003():
>> pass
>>
>> @route('articles//')
>> def year_archive(year):
>>  pass
>>
>> @route('articles///')
>> def month_archive(year, month):
>>  pass
>>
>> @route('articles')
>> def article_detail(year, month, day):
>>  pass
>>
>> @route('articles//')
>> def slug_view(slug):
>>  pass
>>
>>
>>
>>
>>
>>
>> *Pyramid*
>> This one is kind of interesting. They don't have any built in validators.
>> And they call their equivalent predicates
>> ,
>> and their usage is far more board.
>>
>> config.add_route('special_case_2003', 'articles/2003/')
>> config.add_route('year_archive', 'articles/{year}/')
>> config.add_route('month_archive', 'articles/{year}/{month}/')
>> config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
>> config.add_route('slug_view', 'articles/{slug}/')
>> config.scan()
>>
>>
>>
>>
>>
>>
>> Robert Roskam
>>
>> On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>>>
>>> Hi folks,
>>>
>>> I wanted to push forward the consideration of introducing a simpler URLs
>>> syntax, plus support for URL parameter type conversion.
>>>
>>> A pre-proposal is available here: https://gist.github.com/tomchr
>>> istie/cb388f0f6a0dec931c611775f32c5f98
>>>
>>> At this point I'm seeking feedback, before hopefully iterating on the
>>> proposal, and making a formal submission.
>>>
>>> I'm not making any assumptions right now about where this might get too,
>>> or who'd be involved if it does make it to the DEP stage, and would very
>>> much welcome outside involvement. I'm also aware that while there's been
>>> some positive reception, it's not yet clear if we'll reach a consensus on
>>> inclusion in core.
>>>
>>> Personally I'm very firmly +1 on

Re: DEP pre-proposal for a simpler URLs syntax.

[Robert Roskam]

Hey All,

Sorry all. I accidentally submitted my message somehow.

I wanted to say that I like the direction Django is going compared to the 
other Python frameworks for its routing. I've looked at Express.js, 
angularjs, rails, and MVC.NET as well. And Django is definitely the easiest 
to read among them.

I think this syntax offers both simplicity in not missing dumb stuff like 
the leading ^ and the trailing $, but it also lets us work toward more 
expressive routing patterns in the future.

Robert Roskam

On Wednesday, October 5, 2016 at 4:08:08 PM UTC-4, Robert Roskam wrote:
>
> Hey Tom,
>
> I really like your current implementation. I think it's an elegant 
> solution to a complex problem, and I like that you looked at Flask for some 
> inspiration. 
>
> I thought that to round out the discussion I'd do a quick comparison to 
> other frameworks. (I've added in slug examples):
>
> *Django*
>
> urlpatterns = [ 
> url(r'^articles/2003/$', views.special_case_2003),
> url(r'^articles/(?P[0-9]{4})/$', views.year_archive),
> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/$', 
> views.month_archive),
> url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/(?P[0-9]{2})/$', 
> views.article_detail),url(r'^articles/(?P[\w-]+)/$', 
> views.slug_view),
> ]
>
>
>
> *DEP*
>
> urlpatterns = [ 
> path('articles/2003/', views.special_case_2003),
> path('articles//', views.year_archive),
> path('articles///', views.month_archive),
> path('articles', views.article_detail), 
>path('articles//', views.slug_view),
> ]
>
>
>
>
>
> *Flask*
> Doesn't really have the idea of putting all your routes in one spot. So 
> pardon the silly example.
>
> 
> @app.route('articles/2003/') 
> def special_case_2003():
>   pass
>
> @app.route('articles//') 
> def year_archive(year):
>   pass
>
> @app.route('articles///') 
> def month_archive(year, month):
>   pass
>
> @app.route('articles') 
> def article_detail(year, month, day):
>   pass
>
> @app.route('articles//')
> def slug_view(slug):
>   pass
>
>
>
>
> *Bottle*
> It's basically Flask (big surprise).
>
> @route('articles/2003/') 
> def special_case_2003():
> pass
>
> @route('articles//')
> def year_archive(year):
>   pass
>
> @route('articles///')
> def month_archive(year, month):
>   pass
>
> @route('articles') 
> def article_detail(year, month, day):
>   pass
>
> @route('articles//')
> def slug_view(slug):
>   pass
>
>
>
>
>
>
> *Pyramid*
> This one is kind of interesting. They don't have any built in validators. 
> And they call their equivalent predicates 
> ,
>  
> and their usage is far more board. 
>
> config.add_route('special_case_2003', 'articles/2003/')
> config.add_route('year_archive', 'articles/{year}/')
> config.add_route('month_archive', 'articles/{year}/{month}/')
> config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
> config.add_route('slug_view', 'articles/{slug}/')
> config.scan()
>
>
>
>
>
>
> Robert Roskam
>
> On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>>
>> Hi folks,
>>
>> I wanted to push forward the consideration of introducing a simpler URLs 
>> syntax, plus support for URL parameter type conversion.
>>
>> A pre-proposal is available here: 
>> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>>
>> At this point I'm seeking feedback, before hopefully iterating on the 
>> proposal, and making a formal submission.
>>
>> I'm not making any assumptions right now about where this might get too, 
>> or who'd be involved if it does make it to the DEP stage, and would very 
>> much welcome outside involvement. I'm also aware that while there's been 
>> some positive reception, it's not yet clear if we'll reach a consensus on 
>> inclusion in core.
>>
>> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
>> is a rather glaring and unnecessary pain point.
>>
>> Thanks to everyone who's started to kick this off, in particular Emil 
>> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
>> work on the Django Simple URL 
>>  package.
>>
>>   - Tom
>>
>

-- 
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/db1f38e2-3716-41d0-870e-ea7b84d0cfc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Robert Roskam]

Hey Tom,

I really like your current implementation. I think it's an elegant solution 
to a complex problem, and I like that you looked at Flask for some 
inspiration. 

I thought that to round out the discussion I'd do a quick comparison to 
other frameworks. (I've added in slug examples):

*Django*

urlpatterns = [ 
url(r'^articles/2003/$', views.special_case_2003),
url(r'^articles/(?P[0-9]{4})/$', views.year_archive),
url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/$', 
views.month_archive),
url(r'^articles/(?P[0-9]{4})/(?P[0-9]{2})/(?P[0-9]{2})/$', 
views.article_detail),url(r'^articles/(?P[\w-]+)/$', views.slug_view),
]



*DEP*

urlpatterns = [ 
path('articles/2003/', views.special_case_2003),
path('articles//', views.year_archive),
path('articles///', views.month_archive),
path('articles', views.article_detail),   
 path('articles//', views.slug_view),
]





*Flask*
Doesn't really have the idea of putting all your routes in one spot. So 
pardon the silly example.


@app.route('articles/2003/') 
def special_case_2003():
pass

@app.route('articles//') 
def year_archive(year):
pass

@app.route('articles///') 
def month_archive(year, month):
pass

@app.route('articles') 
def article_detail(year, month, day):
pass

@app.route('articles//')
def slug_view(slug):
pass




*Bottle*
It's basically Flask (big surprise).

@route('articles/2003/') 
def special_case_2003():
pass

@route('articles//')
def year_archive(year):
pass

@route('articles///')
def month_archive(year, month):
pass

@route('articles') 
def article_detail(year, month, day):
pass

@route('articles//')
def slug_view(slug):
pass






*Pyramid*
This one is kind of interesting. They don't have any built in validators. 
And they call their equivalent predicates 
,
 
and their usage is far more board. 

config.add_route('special_case_2003', 'articles/2003/')
config.add_route('year_archive', 'articles/{year}/')
config.add_route('month_archive', 'articles/{year}/{month}/')
config.add_route('article_detail', 'articles/{year}/{month}/{day}/')
config.add_route('slug_view', 'articles/{slug}/')
config.scan()






Robert Roskam

On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>
> Hi folks,
>
> I wanted to push forward the consideration of introducing a simpler URLs 
> syntax, plus support for URL parameter type conversion.
>
> A pre-proposal is available here: 
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> At this point I'm seeking feedback, before hopefully iterating on the 
> proposal, and making a formal submission.
>
> I'm not making any assumptions right now about where this might get too, 
> or who'd be involved if it does make it to the DEP stage, and would very 
> much welcome outside involvement. I'm also aware that while there's been 
> some positive reception, it's not yet clear if we'll reach a consensus on 
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off, in particular Emil 
> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
> work on the Django Simple URL 
>  package.
>
>   - Tom
>

-- 
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/1177f3c9-fe36-41b4-b6b3-69daae8d8409%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Emil Stenström]

Just a short note from the one that started the first thread after finding 
the regexps hard to read:

Thanks for this Tom, this is exactly what I was looking for! <3

On Monday, 3 October 2016 12:24:04 UTC+2, Tom Christie wrote:
>
> Hi folks,
>
> I wanted to push forward the consideration of introducing a simpler URLs 
> syntax, plus support for URL parameter type conversion.
>
> A pre-proposal is available here: 
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> At this point I'm seeking feedback, before hopefully iterating on the 
> proposal, and making a formal submission.
>
> I'm not making any assumptions right now about where this might get too, 
> or who'd be involved if it does make it to the DEP stage, and would very 
> much welcome outside involvement. I'm also aware that while there's been 
> some positive reception, it's not yet clear if we'll reach a consensus on 
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax 
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off, in particular Emil 
> Stenström for raising the original thread, and Sjoerd Job Postmus for their 
> work on the Django Simple URL 
>  package.
>
>   - Tom
>

-- 
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/4935db5b-a2a5-4c75-93ab-5d07dcc4ada7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Sjoerd Job Postmus]

+1. Looks finished to me. I'd like to contribute on this one way or 
another. I'll try to make sure `django-simple-url` is as compatible with 
this as possible. If need be I'm willing to change the current license if 
it's not compatible with inclusion in Django core.

On Wednesday, October 5, 2016 at 11:59:49 AM UTC+2, Tom Christie wrote:
>
> I've iterated on the pre-proposal, with what I think represents the best 
> options to date.
>
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> The updates are:
>
> * Using a different name for the syntax: `path()`.
> * Dropping the leading slashes.
> * Simplifying the "unintended errors" section.
>
> At some point I'll likely start working towards a validation of this. 
> (Other takers also most welcome.)
> If/when we decided to submit a draft DEP for more in-depth review & 
> consideration, we'll need a shepherd for the proposal. Any takers? (Must be 
> someone from the core team, with commit access.)
>
> Cheers all,
>
>   Tom
>

-- 
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/9fdd77e3-bd26-457c-becc-9060baf921fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP pre-proposal for a simpler URLs syntax.

[Tom Christie]

I've iterated on the pre-proposal, with what I think represents the best 
options to date.

https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98

The updates are:

* Using a different name for the syntax: `path()`.
* Dropping the leading slashes.
* Simplifying the "unintended errors" section.

At some point I'll likely start working towards a validation of this. 
(Other takers also most welcome.)
If/when we decided to submit a draft DEP for more in-depth review & 
consideration, we'll need a shepherd for the proposal. Any takers? (Must be 
someone from the core team, with commit access.)

Cheers all,

  Tom

-- 
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/96e7d90b-e917-40d5-a883-734872724456%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.