Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

Hi! Thank you for review.

Yes i think this would be awesome feature for beginners out of the box.

Also if add it into core, need to think a way to write ‘old-style’ clean regex 
urls. Maybe via any other function or regex parameter type. I think 1% of case 
somebody require this feature.For example by default urlex - regex url pattern, 
url - macros url pattern.

And about urls normalization, i think 99% people use ^ and $ in urls. This must 
be by default too. What you think about it?

About this.

IMHO, option C is too ugly, but option B is the most natural for a beginner to 
use, especially when used with a named group, see point 2.

Maybe, but if combine regex & macro this can make some problems, because of 
this i go simplest way and used colon.

Option A is more Pythonic than option A, but I like option C better.
There you double use option «A». I think this is a mistake.

I think anyway minimalism is good, because django uses KIS (keep it simple) 
principle. Add parameter type is good sometimes, but url doesn’t look clean.

As an option can review one more option - support only combined macro to allow 
user enter «%(name)_%(macro type)» - :product_id, :news_slug, :user_id, 
:post_slug, :post_id, etc.

This will make urls very clean and very strong to misspells. This feature can 
be managed by settings value for example named URL_MACRO_ALLOW_SHORT = False by 
default.

-- 
Alexandr Shurigin

From: Mardini Moayad moaya...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 2 июня 2014 г. at 13:51:53
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple  

Hi Alexandr,

Thanks for the nice suggestion. It's good to try to improve Django in an area 
you think it might be lacking.

I also think this is a really nice feature to add to the framework, which will 
make it more beginner-friendly.

I'll try to discuss what I think is the most important features that should be 
considered in a potential new resolver that might be added to the core. There 
are currently many options to start with, including:
Surlex: https://github.com/codysoyland/surlex
hurl: https://github.com/oinopion/hurl
smarturls: https://github.com/amitu/smarturls/
Django Macros Url: https://github.com/phpdude/django-macros-url/
Regex Builder: https://github.com/bruntonspall/regex-builder

The features include:

1) The syntax of the new URL:
Since the whole point of introducing another URL resolver is to make the syntax 
simpler, I think this is the most important feature.
The options are:
A) The colon syntax: url('news/:year/:month/:day$', 'news_view')
B) An angle brackets tag syntax: surl('news///', 'news_view')
C) A chain of function calls: str(repeats(literal('a'),2,3))

IMHO, option C is too ugly, but option B is the most natural for a beginner to 
use, especially when used with a named group, see point 2.

2) How expressive the patterns names are:
A) Expressive, reflects what the real regex will be: 
B) The predefined pattern uses a simple name :  
C) Minimalist, where the name of the predefined pattern will be automatically 
be used as a named group:  (I'm not sure if this approach is used by any 
library or whether it's a good one, I just though of it and added it for 
completeness.)

3) Extending the predefined patterns:
A) Using a dictionary: h.matchers['year'] = r'\d{4}'
B) Using a function call: macrosurl.register('myhash', '[a-f0-9]{9}')
C) Using a setting in settings.py: SURL_REGEXERS = { ... }

Option A is more Pythonic than option A, but I like option C better.

Thanks.

On Saturday, May 31, 2014 10:44:33 PM UTC+3, Alexandr Shurigin wrote:
hi all.

I developed first version of application, you can take a look into it.

https://github.com/phpdude/django-macros-url/

You can take a look into tests to see for really big url patterns :))

Library is simple as possible and makes a lot of extra work.

I think some type of library must be in core, what you think?

Thanks

-- 
Alexandr Shurigin

From: Shurigin Alexandr alexandr...@gmail.com
Reply: Shurigin Alexandr alexandr...@gmail.com
Date: 29 мая 2014 г. at 3:07:17
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

happy Urls doesn’t look simpler, just splitter configuration to parts .. This 
doesn’t make urls more readable i think. Sometimes this way is good, but not 
always.


-- 
Alexandr Shurigin

From: Tamlyn Marc marc@gmail.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 29 мая 2014 г. at 2:51:41
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

I'm in favour of introducing another URL resolver, as a simpler option not as a 
replacement. My motivation is not "because it's nicer", rather to lower the 
boundary to entry. The Regex syntax is difficult for beginners.

There are many competing 

Re: Make url patterns group kwargs more simple

[Moayad Mardini]

Sorry for the typo. I meant to say that I think option A is more Pythonic
than option B.

I personally like the approach Marc suggested, which is introducing another
URL resolver, rather than modifying the existing one.

Moayad
On 2 Jun 2014 12:36, "Alexandr Shurigin" 
wrote:

> Hi! Thank you for review.
>
> Yes i think this would be awesome feature for beginners out of the box.
>
> Also if add it into core, need to think a way to write ‘old-style’ clean
> regex urls. Maybe via any other function or regex parameter type. I think
> 1% of case somebody require this feature.For example by default urlex -
> regex url pattern, url - macros url pattern.
>
> And about urls normalization, i think 99% people use ^ and $ in urls. This
> must be by default too. What you think about it?
>
> About this.
>
> IMHO, option C is too ugly, but option B is the most natural for a
> beginner to use, especially when used with a named group, see point 2.
>
>
> Maybe, but if combine regex & macro this can make some problems, because
> of this i go simplest way and used colon.
>
> Option A is more Pythonic than option A, but I like option C better.
>
> There you double use option «A». I think this is a mistake.
>
> I think anyway minimalism is good, because django uses KIS (keep it
> simple) principle. Add parameter type is good sometimes, but url doesn’t
> look clean.
>
> As an option can review one more option - support only combined macro to
> allow user enter «%(name)_%(macro type)» - :product_id, :news_slug,
> :user_id, :post_slug, :post_id, etc.
>
> This will make urls very clean and very strong to misspells. This feature
> can be managed by settings value for example named URL_MACRO_ALLOW_SHORT =
> False by default.
>
> --
> Alexandr Shurigin
>
> From: Mardini Moayad moaya...@gmail.com
> Reply: django-developers@googlegroups.com
> django-developers@googlegroups.com
> Date: 2 июня 2014 г. at 13:51:53
> To: django-developers@googlegroups.com django-developers@googlegroups.com
> Subject:  Re: Make url patterns group kwargs more simple
>
>  Hi Alexandr,
>
> Thanks for the nice suggestion. It's good to try to improve Django in an
> area you think it might be lacking.
>
> I also think this is a really nice feature to add to the framework, which
> will make it more beginner-friendly.
>
> I'll try to discuss what I think is the most important features that
> should be considered in a potential new resolver that might be added to the
> core. There are currently many options to start with, including:
>  *Surlex*: https://github.com/codysoyland/surlex
> *hurl*: https://github.com/oinopion/hurl
>  *smarturls*: https://github.com/amitu/smarturls/
> *Django Macros Url*: https://github.com/phpdude/django-macros-url/
> *Regex Builder*: https://github.com/bruntonspall/regex-builder
>
> The features include:
>
> *1) The syntax of the new URL:*
> Since the whole point of introducing another URL resolver is to make the
> syntax simpler, I think this is the most important feature.
> The options are:
> A) The colon syntax: url('news/:year/:month/:day$', 'news_view')
> B) An angle brackets tag syntax: surl('news///', '
> news_view')
> C) A chain of function calls: str(repeats(literal('a'),2,3))
>
> IMHO, option C is too ugly, but option B is the most natural for a
> beginner to use, especially when used with a named group, see point 2.
>
> *2) How expressive the patterns names are:*
> A) Expressive, reflects what the real regex will be: 
> B) The predefined pattern uses a simple name :  
> C) Minimalist, where the name of the predefined pattern will be
> automatically be used as a named group:  (I'm not sure if this
> approach is used by any library or whether it's a good one, I just though
> of it and added it for completeness.)
>
> *3) Extending the predefined patterns:*
> A) Using a dictionary: h.matchers['year'] = r'\d{4}'
> B) Using a function call: macrosurl.register('myhash', '[a-f0-9]{9}')
> C) Using a setting in settings.py: SURL_REGEXERS = { ... }
>
> Option A is more Pythonic than option A, but I like option C better.
>
> Thanks.
>
> On Saturday, May 31, 2014 10:44:33 PM UTC+3, Alexandr Shurigin wrote:
>>
>>  hi all.
>>
>>  I developed first version of application, you can take a look into it.
>>
>>  https://github.com/phpdude/django-macros-url/
>>
>>  You can take a look into tests to see for really big url patterns :))
>>
>>  Library is simple as possible and makes a lot of extra work.
>>
>>  I think some type of library must be in core, what you think?
>>
>>  Thanks
>>
>>  --
>> Alexandr Shurigin
>>
>> From: Shurigin Alexandr alexandr...@gmail.com
>> Reply: Shurigin Alexandr alexandr...@gmail.com
>> Date: 29 мая 2014 г. at 3:07:17
>> To: django-d...@googlegroups.com django-d...@googlegroups.com
>> Subject:  Re: Make url patterns group kwargs more simple
>>
>>   happy Urls doesn’t look simpler, just splitter configuration to parts
>> .. This doesn’t make urls more readable i think. Sometimes this way is
>> good, but not always.
>>
>>

Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

Sorry for the typo. I meant to say that I think option A is more Pythonic than 
option B.

No problem :)

I used function for possibility to support parameters filtering in future. 
Maybe to add macro name validation or pattern.

I personally like the approach Marc suggested, which is introducing another URL 
resolver, rather than modifying the existing one.

Very good idea too.

But will it make any overhead or problems i don’t know for now, because know 
django core not soo deep for now. Use it as primary framework only for about 6 
months. But backends and pipelines style is very good i think anyway.




Moayad

On 2 Jun 2014 12:36, "Alexandr Shurigin"  wrote:
Hi! Thank you for review.

Yes i think this would be awesome feature for beginners out of the box.

Also if add it into core, need to think a way to write ‘old-style’ clean regex 
urls. Maybe via any other function or regex parameter type. I think 1% of case 
somebody require this feature.For example by default urlex - regex url pattern, 
url - macros url pattern.

And about urls normalization, i think 99% people use ^ and $ in urls. This must 
be by default too. What you think about it?

About this.

IMHO, option C is too ugly, but option B is the most natural for a beginner to 
use, especially when used with a named group, see point 2.

Maybe, but if combine regex & macro this can make some problems, because of 
this i go simplest way and used colon.

Option A is more Pythonic than option A, but I like option C better.
There you double use option «A». I think this is a mistake.

I think anyway minimalism is good, because django uses KIS (keep it simple) 
principle. Add parameter type is good sometimes, but url doesn’t look clean.

As an option can review one more option - support only combined macro to allow 
user enter «%(name)_%(macro type)» - :product_id, :news_slug, :user_id, 
:post_slug, :post_id, etc.

This will make urls very clean and very strong to misspells. This feature can 
be managed by settings value for example named URL_MACRO_ALLOW_SHORT = False by 
default.

-- 
Alexandr Shurigin

From: Mardini Moayad moaya...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 2 июня 2014 г. at 13:51:53
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

Hi Alexandr,

Thanks for the nice suggestion. It's good to try to improve Django in an area 
you think it might be lacking.

I also think this is a really nice feature to add to the framework, which will 
make it more beginner-friendly.

I'll try to discuss what I think is the most important features that should be 
considered in a potential new resolver that might be added to the core. There 
are currently many options to start with, including:
Surlex: https://github.com/codysoyland/surlex
hurl: https://github.com/oinopion/hurl
smarturls: https://github.com/amitu/smarturls/
Django Macros Url: https://github.com/phpdude/django-macros-url/
Regex Builder: https://github.com/bruntonspall/regex-builder

The features include:

1) The syntax of the new URL:
Since the whole point of introducing another URL resolver is to make the syntax 
simpler, I think this is the most important feature.
The options are:
A) The colon syntax: url('news/:year/:month/:day$', 'news_view')
B) An angle brackets tag syntax: surl('news///', 'news_view')
C) A chain of function calls: str(repeats(literal('a'),2,3))

IMHO, option C is too ugly, but option B is the most natural for a beginner to 
use, especially when used with a named group, see point 2.

2) How expressive the patterns names are:
A) Expressive, reflects what the real regex will be: 
B) The predefined pattern uses a simple name :  
C) Minimalist, where the name of the predefined pattern will be automatically 
be used as a named group:  (I'm not sure if this approach is used by any 
library or whether it's a good one, I just though of it and added it for 
completeness.)

3) Extending the predefined patterns:
A) Using a dictionary: h.matchers['year'] = r'\d{4}'
B) Using a function call: macrosurl.register('myhash', '[a-f0-9]{9}')
C) Using a setting in settings.py: SURL_REGEXERS = { ... }

Option A is more Pythonic than option A, but I like option C better.

Thanks.

On Saturday, May 31, 2014 10:44:33 PM UTC+3, Alexandr Shurigin wrote:
hi all.

I developed first version of application, you can take a look into it.

https://github.com/phpdude/django-macros-url/

You can take a look into tests to see for really big url patterns :))

Library is simple as possible and makes a lot of extra work.

I think some type of library must be in core, what you think?

Thanks

-- 
Alexandr Shurigin

From: Shurigin Alexandr alexandr...@gmail.com
Reply: Shurigin Alexandr alexandr...@gmail.com
Date: 29 мая 2014 г. at 3:07:17
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple

happy Urls doesn’t lo

Re: Make url patterns group kwargs more simple

[Aymeric Augustin]

> Le 2 juin 2014 à 11:36, Alexandr Shurigin  a 
> écrit :
> 
> And about urls normalization, i think 99% people use ^ and $ in urls. This 
> must be by default too. What you think about it?

Probably true for ^, but not for $ which must not be present for includes.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97618885-FC3E-4160-801C-03325ABEA485%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Make url patterns group kwargs more simple

[Alexandr Shurigin]

really? this is my fault :)

i forget about this.

need to fix this in lib:)

But if implement same style route classes in core, there we have context - is 
view or included and make choose about ending $ automatically.
-- 
Alexandr Shurigin

From: Augustin Aymeric aymeric.augustin.2...@polytechnique.org
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 2 июня 2014 г. at 18:49:15
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject:  Re: Make url patterns group kwargs more simple  

> Le 2 juin 2014 à 11:36, Alexandr Shurigin  a 
> écrit :  
>  
> And about urls normalization, i think 99% people use ^ and $ in urls. This 
> must be by default too. What you think about it?  

Probably true for ^, but not for $ which must not be present for includes.  

--  
Aymeric.  

--  
You received this message because you are subscribed to the Google Groups 
"Django developers" group.  
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.  
To post to this group, send email to django-developers@googlegroups.com.  
Visit this group at http://groups.google.com/group/django-developers.  
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97618885-FC3E-4160-801C-03325ABEA485%40polytechnique.org.
  
For more options, visit https://groups.google.com/d/optout.  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.538c660c.2eb141f2.152%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

Re: FormWizard needs confirmation step logic. ticket #21644

[Gordon]

How would that work?  Being part of contrib is a big plus for the app in many 
ways.  I am not familiar with another app that was removed from contrib that 
would show an overview of the process and if it was successful.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a5e02ac8-576a-4ed5-9c28-a57644a6143b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FormWizard needs confirmation step logic. ticket #21644

[Thomas Leo]

The company I'm currently contracting for, makes heavy use of formtools, 
I'd be disappointed to see it go.

On Monday, May 26, 2014 6:04:31 PM UTC-4, Tim Graham wrote:
>
> My observation is that not many core developers seem interested in 
> contrib.formtools these days. It was added by Adrian in 2006, but as far as 
> I can see from the commit history, it hasn't received much love lately. If 
> would be a good candidate for deprecation from Django itself, in my opinion.
>
> On Monday, May 26, 2014 3:32:41 PM UTC-4, Gordon wrote:
>>
>> Hello,
>>
>> I have posted an implementation/proof of concept to ticket 21644 (
>> https://code.djangoproject.com/ticket/21644).  The implementation is 
>> currently written as a mixin because I need to be able to use it now and I 
>> don't like maintaining a custom fork of django for my projects.  If changed 
>> to update the base classes directly, the diff would be minimal.
>>
>> I am happy to work on FormWizard improvements because they are 
>> particularly useful for some of my projects, but I haven't had much of a 
>> response.  Since this is a contrib app bundled with django, I am hesitant 
>> to spend too much time on it without some sort of positive and/or 
>> constructive feedback from someone who can accept the changes.
>>
>> On topic... the brief summary for #21644 is that this allows for 
>> "confirmation" steps in a formwizard that have access to the data submitted 
>> for previous steps.  This is required for something like a checkout 
>> confirmation or anything where the user needs to be presented with data 
>> entered previously for acceptance to be meaningful.  It was important to my 
>> use case that the wizard supports multiple confirmation steps.  I've used a 
>> base class that confirmation forms should inherit from to detect when 
>> confirmation logic should be used.  This allows for a backwards 
>> compatible opt-in approach.
>>
>> Thanks,
>> Gordon
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/937dcfa8-ac6d-42ef-ae86-78eee324f171%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FormWizard needs confirmation step logic. ticket #21644

[Tim Graham]

contrib.databrowse is an example of something that was removed from Django. 
It seems to have found a home here: 
https://pypi.python.org/pypi/django-databrowse

Deprecation of contrib.formtools was actually proposed on the mailing list 
in 2011, see 
https://groups.google.com/d/topic/django-developers/P_WMxmOCJFY/discussion

At that time Carl and Jannis were -0 due to some recent improvements. I 
wonder if they feel any differently now.

Jannis: "FYI, formtools is unlikely to go away anytime soon, as we've just
recently added a new class based views wizard [1]. Next step would
be to refactor the form preview tool to be class based, too [2].

1: https://docs.djangoproject.com/en/dev/releases/1.4/#new-form-wizard
2: https://code.djangoproject.com/ticket/16174

Carl: "-0 on formtools at this point for the same reason Jannis
mentioned; it is actually actively maintained and used, and recently got
some major improvements. In the abstract I do think that formtools is a
fine candidate to be an external app rather than live in contrib, I just
think we may as well start with the lower-hanging fruit here."


On Monday, June 2, 2014 2:27:07 PM UTC-4, Gordon wrote:
>
> How would that work?  Being part of contrib is a big plus for the app in 
> many ways.  I am not familiar with another app that was removed from 
> contrib that would show an overview of the process and if it was successful.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ad1f913-4508-41d9-ab8e-e2076f83839f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add an extra parameter to 'static' tag

[Renato Oliveira]

Thanks for the answers!





Renato Oliveira
@_renatooliveira 
Labcodes - www.labcodes.com.br



On Sun, Jun 1, 2014 at 8:26 PM, Florian Apolloner 
wrote:

> Hi Renato,
>
>
> On Sunday, June 1, 2014 4:36:55 PM UTC+2, Renato Oliveira wrote:
>>
>> On Sunday, June 1, 2014 3:26:06 AM UTC+2, Renato Oliveira wrote:

 I open sourced  the
 modification we did (4 or 5 lines plus tests), and was about to send it to
 pypi and wondered if it is an improvement to do on Django itself.

>>>
>>> I don't think so, since Django already provides a way to do what you are
>>> after: You can write your on static storage backend which the static-tag
>>> will then use, this way the backend will figure out what to do when
>>> DEBUG=False/True.
>>>
>>
>> Yeah, i'm aware of this, and sorry for not being explicit. The goal of
>> this improvement is to point to many places. For exampe, if I have a
>> project with, bootstrap, jquery and angular. I can do this:
>>
>> {% static 'path/to/my/angular.js' http://googlecdn/angular.js %}
>> {% static 'path/to/bootstrap.css' http://bootstrapcdn/bootstrap.css %}
>>
>
> I don't see any difference to the  DEBUG example here, a storage backend
> can still return different URLs, depending on the filename (eg angular vs
> bootstrap). Your proposal seems to remove the choice from the user and puts
> it into the template. FWIW, in my experience per project CDNs often
> introduce greater latency and less performance than a single (or more)
> keep-alive connections to one server fetching all the files (possible
> concatenated).
>
> Cheers,
> Florian
>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d7da3542-f64e-4aed-83c0-4d56070d9d01%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGPLouUU8c5zQn%2BPGZ3OnCw%3D0x85qKx1au3YN4OOtnQpa7iLbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Changing development server threads type.

[Moayad Mardini]

Hi,

The development server currently uses "non-daemon threads" for 
the socketserver, this has many bad side effects, as discussed in ticket 
#21773 ( https://code.djangoproject.com/ticket/21773 ).
The most annoying disadvantages of that are:
1) Longer time to restart, because the sever has to make sure everything is 
finished before it can auto-reload, I don't think this is a good behavior 
because since it's a development server, you are always intentionally 
causing the auto-reload.
2) If something goes wrong, like a bad view, there is no way to quit or 
restart the server, without manually killing its process from the OS.

I made a patch: https://github.com/django/django/pull/2690 that changes the 
default threads type of the server to be daemon threads, and introduced a 
command option "runserver --nodaemon" to use non-daemon threads if the user 
still prefers that for one reason or another.

I'm aware that the core developers are reluctant to merge any big change 
without a discussion first, so I'm asking about your opinions about that 
change and the patch.

Thanks a lot,

Moayad

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b1bf66a0-d6aa-4168-a566-6d8a099a7096%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.