Re: Challenge teaching Django to beginners: urls.py

[Marc Tamlyn]

Fwiw, I spent a little time investigating this a couple of years ago. I
would like to see Django officially bless the idea of alternative URL
systems, and provide the "full" regex system and preferably at least one
"simple" system - even if all that system supports is integers and slugs.
This would allow third party authors to focus on designing their "to regex"
translation, rather than the details of Django's resolving.

I did some investigation into swapping at a "deeper" level, including
allowing mixed includes from one resolver type to another. This is made
somewhat harder by the removal of "patterns", and was much more complex.
However it did give much more flexibility in allowing URL patterns which
route based on other attributes than the path. I dont have any working
code, it was very conceptual. I think we should at least consider a more
dramatic approach in a DEP, even if it is not the intended course.

Marc

On 15 Sep 2016 9:52 a.m., "Sjoerd Job Postmus"  wrote:

>
>
> 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.
>
> --
> 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/d9db908b-d22b-428f-908a-
> ecdc34b8fbfb%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-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/CAMwjO1HjuF8_c-sZef4oByK%3DrZKz4aWTPp1OvSS%3DGGRaqGOfQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working towards a simpler GCBV implementation?

[Asif Saifuddin]

Hi Tom,

I am basically +1 to see this change in the django core. The package is 3 
years old and should be tested enough. If you/other core team members 
thinks that now is a good time to include it to core and deprecation of 
older API, then I will be willing to work and send PR for this.

Looking for others opinions.

Thanks,

Asif

On Thursday, October 3, 2013 at 3:09:58 PM UTC+6, Tom Christie wrote:
>
> Hi folks,
>
> I recently released an alternative implementation of Django's existing 
> class based views.  The intention was to mirror the *exact* same set of 
> functionality that we currently provide, but simplify the implementation 
> and API.  It's nothing cleverer or grander than a clean re-write, but the 
> end result is *significantly* less complex.  The class hierarchy is 
> trivial, the API is much smaller, and the flow control is much more obvious.
>
> I won't go into any more here, as there's plenty of detail in the 
> documentation:
>
> http://django-vanilla-views.org
>
> There's also useful context in the related blog post, here:
>
> http://dabapps.com/blog/fixing-djangos-generic-class-based-views/
>
> The difficult thing here really is that there's no obvious approach to 
> introducing something like this in a backwards compatible way.
>
> It might be that we could take an incremental approach using the standard 
> deprecation process, but given the nature of the GCBVs it'd likely be 
> pretty awkward.
> There might be some bits of deprecation process we simply wouldn't be able 
> to deal with in any sensible way, and we'd certainly end up with a 
> seriously gnarly implementation during the deprecation period.
>
> I'd be interested in getting some opinions from folks on the following:
>
> * If a simpler GCBV implementation along the lines of django-vanilla-views 
> is something we think we should working towards.
> * What approaches we might be able to take to dealing with backwards 
> compatibility if we did want to do so.
>
> Thanks for your time.
>
>   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/fc65b52a-df29-48be-8bef-fb6fabb19d97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: missing feature, View permission for django admin

[Olivier Dalang]

Dear List,

In the meantime, there are two failing builds (default and windows) for the
PR .

I can't see what the error is because the links to the build output is a 404
and I wasn't able to
setup a working testing environnement yet. Any help would be greatly
appreciated to fix the PR !!

I really hope we can have this merged in master soon, so that it can be
tested a bit more before release. I'm using it locally (backported to 1.9)
and it works well so far, but it's only for a small project with few users.


Thanks,

Olivier



2016-08-05 11:20 GMT+00:00 Olivier Dalang :

> Hi,
>
> As 1.10 is out now, I'd like to draw your attention again on this feature,
> still hoping to see it merged as soon as possible in the release process so
> that we get as much testing as possible.
>
> Thanks for all the great work,
>
> Olivier Dalang
>
>
>
> 2016-06-15 12:01 GMT+00:00 Tim Graham :
>
>> Just to give you my perspective so you don't feel ignored, after the 1.10
>> release is a better for reviewing and merging larger features than right
>> now.
>>
>> On Wednesday, June 15, 2016 at 7:40:44 AM UTC-4, Olivier Dalang wrote:
>>>
>>> Hi,
>>>
>>> I worked a bit on this feature lately. I rebased PetrDlouhy's great work
>>> (PR 5297 ) onto master in a
>>> new PR 6734 .
>>>
>>> I think everyone agrees this is a very useful addition to the admin. If
>>> we also agree on the implementation; I suggest to merge as soon as possible
>>> so that we can benefit from as much testing as possible before release, and
>>> more importantly so that third parties have time to adapt their packages
>>> (grappelli...).
>>>
>>> Please let me know if there's anything more I can do.
>>>
>>> I'm really looking forward for this feature, and judging from the
>>> frequency this topic is raised on the ml, I'm not the only one ;)
>>>
>>> Thanks a lot,
>>>
>>> Olivier
>>>
>>>
>>>
>>> On 31 May 2016 13:20, "Tim Graham"  wrote:
>>>
 This feature is tracked in https://code.djangoproject.com/ticket/8936.
 Feel free to review, contribute to, or test the patch if you want to help.

 On Tuesday, May 31, 2016 at 8:26:41 AM UTC-4, Ander Ustarroz wrote:
>
> I am surprised this feature is not implemented yet, at the moment when
> we create a new model  three permissions are created automatically for the
> admin panel:
>
>- *add_permission*
>- *change_permission*
>-
> *delete_permission *
>
> We really missing the *view_permission* here, when we want staff to
> be able to see the content but not being able to modify it. Searching a
> bit,  you can find many different implementations to achieve this, but all
> of them are extending django.contrib.*admin.**ModelAdmin*. Having so
> many people rewriting these methods in my opinion is a clear sign that 
> this
> feature should be part of the core.
>
> Regards,
>
 --
 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.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/django-developers/cfe9b399-2486-4dff-97e6-1c3f94b13f65%4
 0googlegroups.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+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/ms
>> gid/django-developers/4c529e2a-4cd3-4930-b532-c0d0a10c05cc%
>> 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-developers+unsubscr...@googlegrou

Re: Feature request: Generate module docstrings from startproject and startapp actions

[Aymeric Augustin]

Hello Matthew,

I understand the suggestion, however, I’m afraid it priorizes the needs of the 
wrong audience. Experienced developers or teams who care about docstrings and 
pylint can use a custom project template for this use case. Conversely, 
newcomers who are still learning Django would likely leave a docstring stub 
untouched. I lost count of the number of copies of 
https://github.com/django/django/blob/master/django/conf/app_template/tests.py-tpl
 I git-rm’d over the years...

There’s no denying docstrings are useful, but many projects — even large ones — 
are doing just fine without adding one to every single module. I don’t believe 
Django should be exceedingly prescriptive in this regard because I’m afraid 
we’d just encourage the perversion of JavaDoc / PHPDoc / epydoc / etc., that 
is, docstrings written because they’re mandatory and add zero value, like 
"""This module defines the models for billing.”””. Well, it’s called 
`billing/models.py`, I knew that already.

If that requirement was found in PEP 8 or more widely followed by the 
community, I’d be more open to encoding it in the default project template. PEP 
257 sounds a bit self-serving there...

-- 
Aymeric.

> On 15 Sep 2016, at 10:47, Matthew Laney  wrote:
> 
> Hi,
> 
> Going through my code with pylint, I found that there is no way to filter by 
> the type of missing docstring. I.e. missing-docstring catches functions, 
> classes, methods, and modules. As a result, it gives a warning on for every 
> default Django file. Accordingly, I would like to suggest that the current 
> automatically generated comments of "Create your __ here" that are generated 
> for each file created by manage.py startapp be replaced with docstrings that 
> follow the PEP 257 convention. The second line of the specification: All 
> modules should normally have docstrings, and all functions and classes 
> exported by a module should also have docstrings.
> 
> Thanks,
> 
> Matt
> 
> -- 
> 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/29041c35-cc01-464c-9405-d84f1acbc62b%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-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/E6FBEAC7-2D2D-4ADF-94E2-A47B81B62617%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Feature request: Generate module docstrings from startproject and startapp actions

[Matthew Laney]

Hi,

Going through my code with pylint, I found that there is no way to filter 
by the type of missing docstring. I.e. missing-docstring catches functions, 
classes, methods, and modules. As a result, it gives a warning on for every 
default Django file. Accordingly, I would like to suggest that the current 
automatically generated comments of "Create your __ here" that are 
generated for each file created by manage.py startapp be replaced with 
docstrings that follow the PEP 257 convention. The second line of the 
specification: All modules should normally have docstrings, and all 
functions and classes exported by a module should also have docstrings.

Thanks,

Matt

-- 
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/29041c35-cc01-464c-9405-d84f1acbc62b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

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.

-- 
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/d9db908b-d22b-428f-908a-ecdc34b8fbfb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Michal Petrucha]

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 
> ``, 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
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

-- 
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/20160915083755.GU6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Challenge teaching Django to beginners: urls.py

[Florian Apolloner]

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.  

-- 
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/642ce402-4391-4ceb-af7f-b209d70f6667%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

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 
``, 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 Thursday, September 15, 2016 at 9:27:11 AM UTC+2, Anthony King wrote:
>
> 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 
>
> On 15 Sep 2016 8:03 a.m., "Sjoerd Job Postmus"  > wrote:
>
>> Hi :).
>>
>> Yes, I also added the other syntax yesterday evening, so the  
>> 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
>>
>> On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>>>
>>> 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
>>>
>>> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:

 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 
 '' syntax.

 Kind regards,
 Sjoerd Job

 On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:
>
> 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.
>
> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström 
> wrote:
>>
>> 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 wha

Re: Challenge teaching Django to beginners: urls.py

[Anthony King]

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

On 15 Sep 2016 8:03 a.m., "Sjoerd Job Postmus"  wrote:

> Hi :).
>
> Yes, I also added the other syntax yesterday evening, so the 
> 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
>
> On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>>
>> 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
>>
>> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>>
>>> 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
>>> '' syntax.
>>>
>>> Kind regards,
>>> Sjoerd Job
>>>
>>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:

 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.

 On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström
 wrote:
>
> 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///.
>
> 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.
>
> --
> 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/d11376c9-8a6f-45bd-940d-
> bc72589bf8e4%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-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/CALs0z1bz7NyuSL%2B43M1zZqSfsZTV0fgZx_aYGJp79kpsAgGhiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Sjoerd Job Postmus]

Hi :).

Yes, I also added the other syntax yesterday evening, so the  
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

On Thursday, September 15, 2016 at 8:20:03 AM UTC+2, Emil Stenström wrote:
>
> 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
>
> On Wednesday, 14 September 2016 11:02:23 UTC+2, Sjoerd Job Postmus wrote:
>>
>> 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 
>> '' syntax.
>>
>> Kind regards,
>> Sjoerd Job
>>
>> On Tuesday, September 13, 2016 at 9:40:47 PM UTC+2, Tim Graham wrote:
>>>
>>> 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.
>>>
>>> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:

 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///.

 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.



-- 
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/d11376c9-8a6f-45bd-940d-bc72589bf8e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.