Re: should manage.py test run system checks?

[Marcin Nowak]

As I said some time ago - there should be a possibility to disable system 
checks (generally), and run them only when needed (i.e. by adding 
--system-check argument to mgmt command(s)).

Kind Regards,
Marcin

On Tuesday, October 20, 2015 at 12:02:31 PM UTC+2, Shai Berger wrote:
>
> Just brainstorming : by all of the above, it would seem that the best 
> default is to run checks unless specific tests are selected. Of course, 
> this could be perceived as inconsistent, and that would be a problem. 
>
> On 20 באוקטובר 2015 10:04:17 GMT+03:00, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>>
>> 2015-10-20 2:48 GMT+02:00 Tim Graham :
>>
>>> me: I'm of the opinion that running the system checks as part of the 
>>> manage.py 
>>> test command should be opt-in (for example, by writing a test that 
>>> asserts the call_command('check') output is empty. For example, when 
>>> debugging a single test, it doesn't seem necessary to have the overhead of 
>>> running check. 
>>>
>> I share this opinion. Single-test run time is a very important use case, 
>> not only for TDD practitioners, but also for everyone who tries to fix a 
>> stubborn failing test.
>>
>>
>>
>> -- 
>> Aymeric.
>>
>>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4abd21c6-5499-4a68-9ea6-2a662d622409%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Shai Berger]

Hi,

On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
> Perhaps I'm missing something, but this would not change current users,
> only the creation of new users. It seems that logins would still be case
> sensitive.

Not the way Reid presented it:

> > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
> >> Is it reasonable to consider changing the default for usernames to be
> >> case-insensitive in 2.0?

I think, though, it would be easy enough for us to provide a new, case-
insensitive base class for users, and change the recommendations in our 
documentation to tell users to inherit that rather than the current 
AbstractBaseUser and AbstractUser. We could also write a simple management 
command to validate lower-case uniquness and turn all usernames to lowercase, 
as preparation for changing the login and registration logic.

These could all be done outside of core, and perhaps they should be -- the 
only point I see for including them in core is the risk that, as a developer, 
if core doesn't make you think about it from the get-go, by the time you 
decide to make the change you may be stuck with conflicting (lower-case equal) 
usernames in your database. But frankly, I would guess that this problem does 
not really occur very often; that for most sites, if they decide to switch to 
case-insensitive usernames, there would be no problem.

Regretfully, we can't just switch Django to do that, because of the few sites 
who will have a problem, and no clear upgrade path.

Shai.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Paul Egges]

Perhaps I'm missing something, but this would not change current users,
only the creation of new users. It seems that logins would still be case
sensitive. It would just prevent new users from being created that would
match in a case insensitive manner with an existing user. For example
existing users:

SomeUser and someuser could still use the site in the same manner as the
login process would still be case sensitive. But a new user could not
signup with a username of someUser.



On Wed, Oct 21, 2015 at 1:59 PM, charettes  wrote:

> Hi Reid,
>
> 2.0 is not planned to be a special release in regard to backward
> compatibility.
>
> Since this is a backward incompatible change (what should be done with
> duplicate usernames, etc.) I doubt it's going to happen.
>
> Simon
>
> Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
>>
>> Is it reasonable to consider changing the default for usernames to be
>> case-insensitive in 2.0?
>>
>> On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
>>>
>>> I propose adding a check on UserCreationForm (used by the admin). The
>>> current implementation relies on the model fields unique=True check which
>>> is case-sensitive (except on mysql).
>>>
>>> Whenever I've made a login form, I've always used or made a copy of or
>>> at least studied UserCreationForm. I think if we had a nice walk through of
>>> how to create your own form which included the iexact hint, I think that
>>> would also help solve this problem.
>>>
>>> On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner 
>>> wrote:
>>>


 On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
>
> The suggested change is to not allow a new user if there's a
> username__iexact match.
>

 Yes, but as change to what? To the admin interface? this will only
 cover admin usage. To a full_clean of the user model [This is often not
 used anyways]? I am somewhat against that…

 --
 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 http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a7c3add7-d13d-4b5c-af73-ac74cbc1c6a0%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD4jHOLL_PqyERHO4ypx-j%3Dp8K%3Dz1vZc8jBo1roZh_LL2zHWag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[charettes]

Hi Reid,

2.0 is not planned to be a special release in regard to backward 
compatibility.

Since this is a backward incompatible change (what should be done with
duplicate usernames, etc.) I doubt it's going to happen.

Simon

Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
>
> Is it reasonable to consider changing the default for usernames to be 
> case-insensitive in 2.0?
>
> On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
>>
>> I propose adding a check on UserCreationForm (used by the admin). The 
>> current implementation relies on the model fields unique=True check which 
>> is case-sensitive (except on mysql).
>>
>> Whenever I've made a login form, I've always used or made a copy of or at 
>> least studied UserCreationForm. I think if we had a nice walk through of 
>> how to create your own form which included the iexact hint, I think that 
>> would also help solve this problem.
>>
>> On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner  
>> wrote:
>>
>>>
>>>
>>> On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:

 The suggested change is to not allow a new user if there's a 
 username__iexact match.

>>>
>>> Yes, but as change to what? To the admin interface? this will only cover 
>>> admin usage. To a full_clean of the user model [This is often not used 
>>> anyways]? I am somewhat against that… 
>>>
>>> -- 
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7c3add7-d13d-4b5c-af73-ac74cbc1c6a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Reid Ransom]

Is it reasonable to consider changing the default for usernames to be 
case-insensitive in 2.0?

On Sunday, August 30, 2015 at 12:11:35 PM UTC-4, Collin Anderson wrote:
>
> I propose adding a check on UserCreationForm (used by the admin). The 
> current implementation relies on the model fields unique=True check which 
> is case-sensitive (except on mysql).
>
> Whenever I've made a login form, I've always used or made a copy of or at 
> least studied UserCreationForm. I think if we had a nice walk through of 
> how to create your own form which included the iexact hint, I think that 
> would also help solve this problem.
>
> On Sun, Aug 30, 2015 at 6:43 AM, Florian Apolloner  > wrote:
>
>>
>>
>> On Saturday, August 29, 2015 at 9:59:30 PM UTC+2, Tim Graham wrote:
>>>
>>> The suggested change is to not allow a new user if there's a 
>>> username__iexact match.
>>>
>>
>> Yes, but as change to what? To the admin interface? this will only cover 
>> admin usage. To a full_clean of the user model [This is often not used 
>> anyways]? I am somewhat against that… 
>>
>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/650405a3-c860-4d84-be94-5b6a6c779aa2%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8f02e173-d385-4d96-9dda-1fd6801f97f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrations --exit; exit status feels backwards from conventions

[Jon Dufresne]

On Tue, Oct 20, 2015 at 9:29 PM, Gavin Wahl  wrote:
> In your case, successfully creating a migration indicates a failure.

Only if the --check flag is on. The --check flag indicates that one is
explicitly checking that all model changes have migrations. A non-zero
exist status indicates that migrations were missing. If you feel the
help text could be improved to communicate this, I can work towards
that.

> Why do you object to using a ! to communicate this?

With the --check flag or the --exit flag?

I think I covered this in the OP. But just to clarify:

My use case:

Continuous integration server check's developers' commits for
correctness. One aspect of correctness is that all model changes have
migrations.

In shell scripting and CI servers an exit status of 0 indicates
true/pass and an exit status of non-zero indicates false/failure.

Therefore, the command should return 0 when everything is OK and
correct and non-zero otherwise. Commits are correct when all model
changes are accounted for.

The current --exit behavior, returns non-zero when everything is
correct. To account for this in CI, one must negate the exit status
with !, this goes against conventional behavior.

Further, if something goes terribly wrong and there is an unhandled
exception, negating the exit status will make the CI stage appear to
pass. This is backwards! CI can't tell the difference between "all
changes accounted for" and "Python had an unhandled exception".


Cheers,
Jon

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b4N24e1TipB-DPCRZxBk71JW0NEs6F_8gKSLDk_ZtQ-tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrating Django with Tornado's web server

[Bastin Robins J]

Hi Bret,

We have built our app using django 1.7 and we need to implement websockets 
for some async purpose. So thought tornado would suit our need
Can you tell me a best practice to achieve this.

On Monday, September 14, 2009 at 2:00:59 AM UTC+5:30, Bret Taylor wrote:
>
> I am one of the authors of Tornado (http://www.tornadoweb.org/), the 
> web server/framework we built at FriendFeed that we open sourced last 
> week (see http://bret.appspot.com/entry/tornado-web-server). 
>
> I just checked in change to Tornado that enables you to run any WSGI- 
> compatible framework on Tornado's HTTP server so that Django apps 
> could run on top of Tornado's HTTP server and benefit from some of the 
> performance work we have done. (I just sent a message to django-users@ 
> with getting started instructions as well, but if you are interested, 
> take a look at 
> http://github.com/facebook/tornado/blob/master/tornado/wsgi.py#L188). 
>
> I chose the WSGI approach because it is generic and applies to all 
> frameworks, but Django is obviously the most widely used. I am curious 
> if there is any benefit to implementing more "native" support in 
> django.core.handlers or if WSGI is the preferred way of adding support 
> for new servers. If there is any performance or usability benefit, let 
> me know, because we would be happy to contribute our time to make it 
> happen. 
>
> In the meantime, if you find any issues with our WSGI support, let me 
> know so we can fix problems. 
>
> Bret 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b05f8edd-891f-4024-9351-01e02c8cbd28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.