Re: Migration Questioner and String-Type Fields

[Tim Graham]

Sure, but I don't think that use case should take priority. It's not much 
work to type an empty string into the questioner if that's what you want. 
If we remove the prompt, it's significantly more work (editing a migration 
file or using RunPython) for a developer to set a non-empty value.

On Friday, September 9, 2016 at 7:19:37 PM UTC-4, Jarek Glowacki wrote:
>
> Instances created afterwards, via `MyModel.objects.create()`, with this 
> field unset won't pass form validation either.
> The use case is where this field is not expected to appear on a Django 
> form.
>
> On Friday, September 9, 2016 at 11:58:38 PM UTC+10, Tim Graham wrote:
>>
>> If blank=False, then a new column with a non-blank value means that all 
>> existing objects won't pass form validation. Therefore, I don't see why a 
>> prompt for a value isn't helpful.
>>
>> On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:
>>>
>>> I made a rant/ticket regarding the hidden usage of `blank` here: #27197 
>>> .
>>>
>>> In short, I don't think that `blank` should dictate whether or not the 
>>> migration questioner runs.
>>> Building on this, I don't think it should run for for string-type fields 
>>> at all. If they have `default` set, use that for existing rows. Else if 
>>> they have `null=True`, set existing rows to `NULL`. Else, set existing rows 
>>> to empty string.
>>>
>>> See linked rant/ticket for some (hopefully) compelling arguments..
>>>
>>> Thoughts?
>>>
>>

-- 
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/8377b6eb-8a2d-4991-988b-50ec93ae7654%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration Questioner and String-Type Fields

[Jarek Glowacki]

Instances created afterwards, via `MyModel.objects.create()`, with this 
field unset won't pass form validation either.
The use case is where this field is not expected to appear on a Django form.

On Friday, September 9, 2016 at 11:58:38 PM UTC+10, Tim Graham wrote:
>
> If blank=False, then a new column with a non-blank value means that all 
> existing objects won't pass form validation. Therefore, I don't see why a 
> prompt for a value isn't helpful.
>
> On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:
>>
>> I made a rant/ticket regarding the hidden usage of `blank` here: #27197 
>> .
>>
>> In short, I don't think that `blank` should dictate whether or not the 
>> migration questioner runs.
>> Building on this, I don't think it should run for for string-type fields 
>> at all. If they have `default` set, use that for existing rows. Else if 
>> they have `null=True`, set existing rows to `NULL`. Else, set existing rows 
>> to empty string.
>>
>> See linked rant/ticket for some (hopefully) compelling arguments..
>>
>> Thoughts?
>>
>

-- 
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/25c683c0-013e-4985-a712-bc5e43decf93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Ivan Sevastoyanov]

Hello,

I installed some older versions of SonarQube and unfortunately the rules 
are not the same and the report generated is not full. But I reviewed the 
issues and I did not find any security issues or something that is 
absolutely critical. There are 40 major issues that are marked as bugs. 
Most common they are of this type - "Having two branches in the same if 
structure with the same implementation is at best duplicate code, and at 
worst a coding error. If the same logic is truly needed for both instances, 
then they should be combined.". So I will write a blog post for setting up 
SonarQube, sonar-scanner and Python plug-in and post it here. It takes not 
more than 15 minutes, so you can see the issues yourself.

Regards,
Ivan

On Tuesday, September 6, 2016 at 3:32:41 PM UTC+3, Ivan Sevastoyanov wrote:
>
> Hello,
>
> I'm back from the vacation.
>
> @Hanne Moa - As far as I know, you can skip packages, files and everything 
> can be customized. It's the same with the rules. I did not prioritized the 
> Sonar rules - they are the default ones and Sonar is detecting not only 
> possible bugs and issues but code smells, some ideas for improving the 
> readability and maintainability, etc. So I agree that these "criticals" 
> are, in fact, not real "criticals" - they are not issues, they will not 
> improve the performance, they are just a tip to improve the readability of 
> the code. But you have the full power to customize the rules and choose 
> which of them are blockers, criticals, major, minor and info.
>
> @Aymeric Augustin - Yes, it's easy to reproduce the results. 
> Unfortunately, I installed the latest version of Sonar and some of the 
> plug-ins for exporting into PDF and HTML are still not compatible. I can 
> install some older version and put an old working plug-in into work. But 
> I'm not sure if the rules will be the same or less than now. I will review 
> the rules and will send an e-mail if I think some of them are security 
> issues. Other I can do is to write a blog post how to install SonarQube and 
> some of the plug-ins and how to configure them but I don't know when I will 
> have enough time for doing that.
>
> @Alex Gaynor - You can see what I wrote to Hanne Moa.
>
> @James Bennett - You can see what I wrote to Hanne Moa. The rules should 
> be prioritized but in my honest opinion I'm not the right person for doing 
> that. I can copy/paste the rules here but I'm not sure that some of them 
> are understandable from their short description.
>
> Regards,
> Ivan
>
> On Monday, September 5, 2016 at 5:40:41 PM UTC+3, James Bennett wrote:
>>
>> On Wed, Aug 31, 2016 at 10:55 AM, Alex Gaynor  wrote:
>>
>>> If these are what qualifies as critical, I don't think this is a good 
>>> use of our time.
>>>
>>>
>>>
>> Agreed. If those are the critical things, then either Django is really 
>> really good, or there are things it's missing. I suspect there are things 
>> it's missing. 
>>
>

-- 
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/e6504461-1617-4691-8b30-6ea48d499a56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels is now an official Django project!

[Chris Foresman]

I'm looking forward to contributing however I can to the project! Exciting 
news!


On Friday, September 9, 2016 at 9:58:24 AM UTC-5, Andrew Godwin wrote:
>
> Hi everyone,
>
> The Technical Board approved Channels as an official Django project as per 
> DEP 7, and so the repositories have been moved under the django/ project on 
> GitHub, as well as a few other things the DEP requires, and improving the 
> contribution guidelines and triaging tickets.
>
> You can read more in the announcement: 
> https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/
>
> If you have any questions about what this means, I'm happy to answer them 
> here! I'm aiming for a 1.0 release reasonably soon, after one or two minor 
> breaking changes that need to be done (there'll be deprecation warning code 
> in there so things don't mysteriously break on upgrade).
>
> Andrew
>

-- 
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/86c1a35f-2491-46db-bd48-023bbde47c96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels is now an official Django project!

[Andrew Godwin]

On Fri, Sep 9, 2016 at 5:07 PM, Tim Graham  wrote:

> Yea, I don't know. I guess it's tough to get feedback when few people have
> a deep understanding of the technical details. That's at least why I didn't
> have any feedback to offer. Proposing it in the middle of the summer when
> people are on generally on vacation might have contributed to the silence.
>

I agree - the summer was maybe the most compounding factor here, along with
the fact that it's really hard to reason and talk about.


>
> Just wanted to give my perspective in case it helps improve the process
> for next time. I'm interested to see how this experiment turns out.
>

Thanks, and I am as well - this is new ground for all of us, I think, and
while I'd like it to end up working fantastically, we can also learn along
the way and work out how to better have Django grow in the next new
direction too.

Andrew


> On Friday, September 9, 2016 at 11:58:41 AM UTC-4, Andrew Godwin wrote:
>>
>> I agree some discussion would be nice, but I tried several times to start
>> some and was met with silence each time. Given the generally positive
>> reaction I've had from everyone I spoke to about the idea, I took it to the
>> technical board, which seemed better than just sitting around with nothing
>> happening.
>>
>> There was a lot of discussion of technical merit of Channels previously
>> during the proposal to merge it in, so I guess everyone felt they had said
>> their piece then? I don't really know, the perspective from where I'm
>> sitting is skewed and people are talking to me about Channels and its
>> merits and downsides constantly.
>>
>> I tried to build on the problems people had with my merge approach and do
>> this slowly, define a process, and get people involved - I'm not sure what
>> else I could have done? Waited another two months?
>>
>> Andrew
>>
>> On Fri, Sep 9, 2016 at 4:51 PM, Tim Graham  wrote:
>>
>>> Thanks, what is missing to me is the technical discussions. Now, I see
>>> there is a draft DEP: https://github.com/django/deps
>>> /blob/master/draft/0006-channels.rst. If that was shared to this list,
>>> I missed it. Perhaps it would have inspired some discussion in your
>>> proposal [0] which didn't get any feedback. That was the oddest part of the
>>> process to me. When you asked for feedback about whether or not the project
>>> should be adopted as an official project, no one said anything and the
>>> default action was to continue the process. It would have been nice to see
>>> some enthusiasm from others about the merits of adopting it as an official
>>> project.
>>>
>>> [0] https://groups.google.com/d/topic/django-developers/24DGLVVR
>>> V_s/discussion
>>>
>>> On Friday, September 9, 2016 at 11:14:25 AM UTC-4, Andrew Godwin wrote:

 Of course - here is the email I sent to the board:

 ---

 Hello everyone,

 As per DEP 7 (https://github.com/django/dep
 s/blob/master/final/0007-official-projects.rst), I would like to
 propose Channels as an official Django project. Specifically, I would like
 to have the following repos as official Django projects:

 andrewgodwin/channels
 andrewgodwin/daphne
 andrewgodwin/asgi_redis
 andrewgodwin/asgi_ipc
 andrewgodwin/asgiref

 I debated whether to not include asgiref and asgi_ipc, but I think it
 is in the project's best interest to have them both as they are both
 valuable and small in scope.

 The proposed shepherd is myself, and the proposed maintenance team is
 myself, Steven Davidson, and Jeremy Spencer. The other two maintainers are
 relatively new to contributing but I aim to mentor them up to full
 maintenance over the coming months; I will also continue to look for a more
 experienced Django community member to help me with this process.

 I will abstain from any vote, but my personal view is that this would
 benefit Django, and that it draws the right balance between not including
 it in core straight away but still having it under the official Django
 umbrella.

 If you have any questions or clarifications, please say and I'm happy
 to discuss.

 ---

 Andrew

 On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham  wrote:

> Could you please share the information that you submitted to the
> technical board as per the DEP: "The Shepherd will submit the project, the
> list of people signed up for the Maintenance Team, and the collated
> arguments to the Technical Board for decision."
>
> In hindsight, I expected that information to be shared on this mailing
> list before project is submitted to the technical board. Would it make
> sense to do that in the future?
>
>
> On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:
>>
>> Hi everyone,
>>
>> The Technical Board approved Channels as an official Django project
>> as per DEP 7, and so the r

Re: Channels is now an official Django project!

[Tim Graham]

Yea, I don't know. I guess it's tough to get feedback when few people have 
a deep understanding of the technical details. That's at least why I didn't 
have any feedback to offer. Proposing it in the middle of the summer when 
people are on generally on vacation might have contributed to the silence.

Just wanted to give my perspective in case it helps improve the process for 
next time. I'm interested to see how this experiment turns out.

On Friday, September 9, 2016 at 11:58:41 AM UTC-4, Andrew Godwin wrote:
>
> I agree some discussion would be nice, but I tried several times to start 
> some and was met with silence each time. Given the generally positive 
> reaction I've had from everyone I spoke to about the idea, I took it to the 
> technical board, which seemed better than just sitting around with nothing 
> happening.
>
> There was a lot of discussion of technical merit of Channels previously 
> during the proposal to merge it in, so I guess everyone felt they had said 
> their piece then? I don't really know, the perspective from where I'm 
> sitting is skewed and people are talking to me about Channels and its 
> merits and downsides constantly.
>
> I tried to build on the problems people had with my merge approach and do 
> this slowly, define a process, and get people involved - I'm not sure what 
> else I could have done? Waited another two months?
>
> Andrew
>
> On Fri, Sep 9, 2016 at 4:51 PM, Tim Graham  > wrote:
>
>> Thanks, what is missing to me is the technical discussions. Now, I see 
>> there is a draft DEP: 
>> https://github.com/django/deps/blob/master/draft/0006-channels.rst. If 
>> that was shared to this list, I missed it. Perhaps it would have inspired 
>> some discussion in your proposal [0] which didn't get any feedback. That 
>> was the oddest part of the process to me. When you asked for feedback about 
>> whether or not the project should be adopted as an official project, no one 
>> said anything and the default action was to continue the process. It would 
>> have been nice to see some enthusiasm from others about the merits of 
>> adopting it as an official project.
>>
>> [0] 
>> https://groups.google.com/d/topic/django-developers/24DGLVVRV_s/discussion
>>
>> On Friday, September 9, 2016 at 11:14:25 AM UTC-4, Andrew Godwin wrote:
>>>
>>> Of course - here is the email I sent to the board:
>>>
>>> ---
>>>
>>> Hello everyone,
>>>
>>> As per DEP 7 (
>>> https://github.com/django/deps/blob/master/final/0007-official-projects.rst),
>>>  
>>> I would like to propose Channels as an official Django project. 
>>> Specifically, I would like to have the following repos as official Django 
>>> projects:
>>>
>>> andrewgodwin/channels
>>> andrewgodwin/daphne
>>> andrewgodwin/asgi_redis
>>> andrewgodwin/asgi_ipc
>>> andrewgodwin/asgiref
>>>
>>> I debated whether to not include asgiref and asgi_ipc, but I think it is 
>>> in the project's best interest to have them both as they are both valuable 
>>> and small in scope.
>>>
>>> The proposed shepherd is myself, and the proposed maintenance team is 
>>> myself, Steven Davidson, and Jeremy Spencer. The other two maintainers are 
>>> relatively new to contributing but I aim to mentor them up to full 
>>> maintenance over the coming months; I will also continue to look for a more 
>>> experienced Django community member to help me with this process.
>>>
>>> I will abstain from any vote, but my personal view is that this would 
>>> benefit Django, and that it draws the right balance between not including 
>>> it in core straight away but still having it under the official Django 
>>> umbrella.
>>>
>>> If you have any questions or clarifications, please say and I'm happy to 
>>> discuss.
>>>
>>> ---
>>>
>>> Andrew
>>>
>>> On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham  wrote:
>>>
 Could you please share the information that you submitted to the 
 technical board as per the DEP: "The Shepherd will submit the project, the 
 list of people signed up for the Maintenance Team, and the collated 
 arguments to the Technical Board for decision."

 In hindsight, I expected that information to be shared on this mailing 
 list before project is submitted to the technical board. Would it make 
 sense to do that in the future?


 On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:
>
> Hi everyone,
>
> The Technical Board approved Channels as an official Django project as 
> per DEP 7, and so the repositories have been moved under the django/ 
> project on GitHub, as well as a few other things the DEP requires, and 
> improving the contribution guidelines and triaging tickets.
>
> You can read more in the announcement: 
> https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/
>
> If you have any questions about what this means, I'm happy to answer 
> them here! I'm aiming for a 1.0 release reasonably soon, after 

Re: Channels is now an official Django project!

[Andrew Godwin]

I agree some discussion would be nice, but I tried several times to start
some and was met with silence each time. Given the generally positive
reaction I've had from everyone I spoke to about the idea, I took it to the
technical board, which seemed better than just sitting around with nothing
happening.

There was a lot of discussion of technical merit of Channels previously
during the proposal to merge it in, so I guess everyone felt they had said
their piece then? I don't really know, the perspective from where I'm
sitting is skewed and people are talking to me about Channels and its
merits and downsides constantly.

I tried to build on the problems people had with my merge approach and do
this slowly, define a process, and get people involved - I'm not sure what
else I could have done? Waited another two months?

Andrew

On Fri, Sep 9, 2016 at 4:51 PM, Tim Graham  wrote:

> Thanks, what is missing to me is the technical discussions. Now, I see
> there is a draft DEP: https://github.com/django/
> deps/blob/master/draft/0006-channels.rst. If that was shared to this
> list, I missed it. Perhaps it would have inspired some discussion in your
> proposal [0] which didn't get any feedback. That was the oddest part of the
> process to me. When you asked for feedback about whether or not the project
> should be adopted as an official project, no one said anything and the
> default action was to continue the process. It would have been nice to see
> some enthusiasm from others about the merits of adopting it as an official
> project.
>
> [0] https://groups.google.com/d/topic/django-developers/
> 24DGLVVRV_s/discussion
>
> On Friday, September 9, 2016 at 11:14:25 AM UTC-4, Andrew Godwin wrote:
>>
>> Of course - here is the email I sent to the board:
>>
>> ---
>>
>> Hello everyone,
>>
>> As per DEP 7 (https://github.com/django/deps/blob/master/final/0007-offic
>> ial-projects.rst), I would like to propose Channels as an official
>> Django project. Specifically, I would like to have the following repos as
>> official Django projects:
>>
>> andrewgodwin/channels
>> andrewgodwin/daphne
>> andrewgodwin/asgi_redis
>> andrewgodwin/asgi_ipc
>> andrewgodwin/asgiref
>>
>> I debated whether to not include asgiref and asgi_ipc, but I think it is
>> in the project's best interest to have them both as they are both valuable
>> and small in scope.
>>
>> The proposed shepherd is myself, and the proposed maintenance team is
>> myself, Steven Davidson, and Jeremy Spencer. The other two maintainers are
>> relatively new to contributing but I aim to mentor them up to full
>> maintenance over the coming months; I will also continue to look for a more
>> experienced Django community member to help me with this process.
>>
>> I will abstain from any vote, but my personal view is that this would
>> benefit Django, and that it draws the right balance between not including
>> it in core straight away but still having it under the official Django
>> umbrella.
>>
>> If you have any questions or clarifications, please say and I'm happy to
>> discuss.
>>
>> ---
>>
>> Andrew
>>
>> On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham  wrote:
>>
>>> Could you please share the information that you submitted to the
>>> technical board as per the DEP: "The Shepherd will submit the project, the
>>> list of people signed up for the Maintenance Team, and the collated
>>> arguments to the Technical Board for decision."
>>>
>>> In hindsight, I expected that information to be shared on this mailing
>>> list before project is submitted to the technical board. Would it make
>>> sense to do that in the future?
>>>
>>>
>>> On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:

 Hi everyone,

 The Technical Board approved Channels as an official Django project as
 per DEP 7, and so the repositories have been moved under the django/
 project on GitHub, as well as a few other things the DEP requires, and
 improving the contribution guidelines and triaging tickets.

 You can read more in the announcement: https://www.djan
 goproject.com/weblog/2016/sep/09/channels-adopted-official-
 django-project/

 If you have any questions about what this means, I'm happy to answer
 them here! I'm aiming for a 1.0 release reasonably soon, after one or two
 minor breaking changes that need to be done (there'll be deprecation
 warning code in there so things don't mysteriously break on upgrade).

 Andrew

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

Re: Channels is now an official Django project!

[Tim Graham]

Thanks, what is missing to me is the technical discussions. Now, I see 
there is a draft DEP: 
https://github.com/django/deps/blob/master/draft/0006-channels.rst. If that 
was shared to this list, I missed it. Perhaps it would have inspired some 
discussion in your proposal [0] which didn't get any feedback. That was the 
oddest part of the process to me. When you asked for feedback about whether 
or not the project should be adopted as an official project, no one said 
anything and the default action was to continue the process. It would have 
been nice to see some enthusiasm from others about the merits of adopting 
it as an official project.

[0] 
https://groups.google.com/d/topic/django-developers/24DGLVVRV_s/discussion

On Friday, September 9, 2016 at 11:14:25 AM UTC-4, Andrew Godwin wrote:
>
> Of course - here is the email I sent to the board:
>
> ---
>
> Hello everyone,
>
> As per DEP 7 (
> https://github.com/django/deps/blob/master/final/0007-official-projects.rst), 
> I would like to propose Channels as an official Django project. 
> Specifically, I would like to have the following repos as official Django 
> projects:
>
> andrewgodwin/channels
> andrewgodwin/daphne
> andrewgodwin/asgi_redis
> andrewgodwin/asgi_ipc
> andrewgodwin/asgiref
>
> I debated whether to not include asgiref and asgi_ipc, but I think it is 
> in the project's best interest to have them both as they are both valuable 
> and small in scope.
>
> The proposed shepherd is myself, and the proposed maintenance team is 
> myself, Steven Davidson, and Jeremy Spencer. The other two maintainers are 
> relatively new to contributing but I aim to mentor them up to full 
> maintenance over the coming months; I will also continue to look for a more 
> experienced Django community member to help me with this process.
>
> I will abstain from any vote, but my personal view is that this would 
> benefit Django, and that it draws the right balance between not including 
> it in core straight away but still having it under the official Django 
> umbrella.
>
> If you have any questions or clarifications, please say and I'm happy to 
> discuss.
>
> ---
>
> Andrew
>
> On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham  > wrote:
>
>> Could you please share the information that you submitted to the 
>> technical board as per the DEP: "The Shepherd will submit the project, the 
>> list of people signed up for the Maintenance Team, and the collated 
>> arguments to the Technical Board for decision."
>>
>> In hindsight, I expected that information to be shared on this mailing 
>> list before project is submitted to the technical board. Would it make 
>> sense to do that in the future?
>>
>>
>> On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:
>>>
>>> Hi everyone,
>>>
>>> The Technical Board approved Channels as an official Django project as 
>>> per DEP 7, and so the repositories have been moved under the django/ 
>>> project on GitHub, as well as a few other things the DEP requires, and 
>>> improving the contribution guidelines and triaging tickets.
>>>
>>> You can read more in the announcement: 
>>> https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/
>>>
>>> If you have any questions about what this means, I'm happy to answer 
>>> them here! I'm aiming for a 1.0 release reasonably soon, after one or two 
>>> minor breaking changes that need to be done (there'll be deprecation 
>>> warning code in there so things don't mysteriously break on upgrade).
>>>
>>> Andrew
>>>
>> -- 
>> 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/msgid/django-developers/d8e29c3b-1cc4-4329-a3ec-968b73417b6f%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/b3f050fb-e5fc-4679-abea-58cf521caed3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging config tries too hard

[Carl Meyer]

On 09/08/2016 11:31 PM, Ivan Sagalaev wrote:
> I'm not familiar with the current deprecation policy in Django. If you
> can point me to it, I could probably carve some time in the nearby
> future and prepare a pull request.

Here is the deprecation policy:
https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation-policy

As it applies to this case, basically we need to ensure that people's
existing logging config continues to function as it does now in the next
release of Django. If they need to make updates to their settings in
order to preserve the same logging behavior, we need a deprecation
warning raised that will alert them to to the need for this change (and
they should be able to silence the deprecation warning by making the
needed change).

I think there's probably some wiggle room in the definition of
"continues to function as it does now." As you pointed out, it's
probably OK if a logger that someone has currently silenced with
disable_existing_loggers=True starts giving output in the next version -
at least that's a change that they are likely to notice and can deal
with as desired. (It should still be noted in the release notes). But
it's a big problem if someone were to silently stop getting logging
output that they currently get.

Carl

-- 
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/492f2fa0-f91c-3730-0821-5bef2376d1f3%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Channels is now an official Django project!

[Andrew Godwin]

Of course - here is the email I sent to the board:

---

Hello everyone,

As per DEP 7 (https://github.com/django/deps/blob/master/final/0007-offic
ial-projects.rst), I would like to propose Channels as an official Django
project. Specifically, I would like to have the following repos as official
Django projects:

andrewgodwin/channels
andrewgodwin/daphne
andrewgodwin/asgi_redis
andrewgodwin/asgi_ipc
andrewgodwin/asgiref

I debated whether to not include asgiref and asgi_ipc, but I think it is in
the project's best interest to have them both as they are both valuable and
small in scope.

The proposed shepherd is myself, and the proposed maintenance team is
myself, Steven Davidson, and Jeremy Spencer. The other two maintainers are
relatively new to contributing but I aim to mentor them up to full
maintenance over the coming months; I will also continue to look for a more
experienced Django community member to help me with this process.

I will abstain from any vote, but my personal view is that this would
benefit Django, and that it draws the right balance between not including
it in core straight away but still having it under the official Django
umbrella.

If you have any questions or clarifications, please say and I'm happy to
discuss.

---

Andrew

On Fri, Sep 9, 2016 at 4:08 PM, Tim Graham  wrote:

> Could you please share the information that you submitted to the technical
> board as per the DEP: "The Shepherd will submit the project, the list of
> people signed up for the Maintenance Team, and the collated arguments to
> the Technical Board for decision."
>
> In hindsight, I expected that information to be shared on this mailing
> list before project is submitted to the technical board. Would it make
> sense to do that in the future?
>
>
> On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:
>>
>> Hi everyone,
>>
>> The Technical Board approved Channels as an official Django project as
>> per DEP 7, and so the repositories have been moved under the django/
>> project on GitHub, as well as a few other things the DEP requires, and
>> improving the contribution guidelines and triaging tickets.
>>
>> You can read more in the announcement: https://www.djan
>> goproject.com/weblog/2016/sep/09/channels-adopted-official-d
>> jango-project/
>>
>> If you have any questions about what this means, I'm happy to answer them
>> here! I'm aiming for a 1.0 release reasonably soon, after one or two minor
>> breaking changes that need to be done (there'll be deprecation warning code
>> in there so things don't mysteriously break on upgrade).
>>
>> Andrew
>>
> --
> 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/d8e29c3b-1cc4-4329-a3ec-968b73417b6f%
> 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/CAFwN1urPt2mOgB%2B-6ODtihnNmaGxGcMWNcoL6ttJmKJmFvK%2BUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels is now an official Django project!

[Tim Graham]

Could you please share the information that you submitted to the technical 
board as per the DEP: "The Shepherd will submit the project, the list of 
people signed up for the Maintenance Team, and the collated arguments to 
the Technical Board for decision."

In hindsight, I expected that information to be shared on this mailing list 
before project is submitted to the technical board. Would it make sense to 
do that in the future?

On Friday, September 9, 2016 at 10:58:24 AM UTC-4, Andrew Godwin wrote:
>
> Hi everyone,
>
> The Technical Board approved Channels as an official Django project as per 
> DEP 7, and so the repositories have been moved under the django/ project on 
> GitHub, as well as a few other things the DEP requires, and improving the 
> contribution guidelines and triaging tickets.
>
> You can read more in the announcement: 
> https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/
>
> If you have any questions about what this means, I'm happy to answer them 
> here! I'm aiming for a 1.0 release reasonably soon, after one or two minor 
> breaking changes that need to be done (there'll be deprecation warning code 
> in there so things don't mysteriously break on upgrade).
>
> Andrew
>

-- 
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/d8e29c3b-1cc4-4329-a3ec-968b73417b6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Channels is now an official Django project!

[Andrew Godwin]

Hi everyone,

The Technical Board approved Channels as an official Django project as per
DEP 7, and so the repositories have been moved under the django/ project on
GitHub, as well as a few other things the DEP requires, and improving the
contribution guidelines and triaging tickets.

You can read more in the announcement:
https://www.djangoproject.com/weblog/2016/sep/09/channels-adopted-official-django-project/

If you have any questions about what this means, I'm happy to answer them
here! I'm aiming for a 1.0 release reasonably soon, after one or two minor
breaking changes that need to be done (there'll be deprecation warning code
in there so things don't mysteriously break on upgrade).

Andrew

-- 
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/CAFwN1uqM4AC%2B5Sm%2Bj7g1Bxm%2B%2BOqAJRKyXqX39%2BoDsGLhgP7q7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't BinaryField use BINARY type?

[Chris Foresman]

That's actually pretty helpful, and sort of gets me closer the what I was 
proposing. I'm just perplexed why there's no support for the VARBINARY type 
similar to the VARCHAR used for CharField. Admittedly I've never had call 
to use this type before, but I just found it surprising that there wasn't a 
clear analog to CharField for bytestrings.


MySQL VARBINARY: 
http://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html
Postgres 
BYTEA: https://www.postgresql.org/docs/current/static/datatype-binary.html
MSSQL VARBINARY: https://msdn.microsoft.com/en-us//library/ms188362.aspx



 
On Thursday, September 8, 2016 at 11:36:03 AM UTC-5, Tim Graham wrote:
>
> Maybe the fields from django-mysql help?
>
> http://django-mysql.readthedocs.io/en/latest/model_fields/resizable_text_binary_fields.html
>
> On Thursday, September 8, 2016 at 10:56:15 AM UTC-4, Chris Foresman wrote:
>>
>> I had a need to store an encrypted bytestring, and CharField doesn't 
>> work. But BinaryField uses LONGBLOB by default (at least on MySQL). Doesn't 
>> it make more sense to have a BinaryField equivalent of CharField, and use 
>> LONGBLOB for something analogous to TextField? As far as I can tell, the 
>> MySQL documentation definitely considers LONGBLOB/BLOB analogous to TEXT. 
>> Not sure the best way to approach an improvement, though; add a 
>> BytestringField? Would this be best served as a third-party package, or 
>> should it be part of Django proper?
>>
>

-- 
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/81a7e504-28f8-4d12-91ae-81cbd3e207da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration Questioner and String-Type Fields

[Tim Graham]

If blank=False, then a new column with a non-blank value means that all 
existing objects won't pass form validation. Therefore, I don't see why a 
prompt for a value isn't helpful.

On Friday, September 9, 2016 at 6:42:02 AM UTC-4, Jarek Glowacki wrote:
>
> I made a rant/ticket regarding the hidden usage of `blank` here: #27197 
> .
>
> In short, I don't think that `blank` should dictate whether or not the 
> migration questioner runs.
> Building on this, I don't think it should run for for string-type fields 
> at all. If they have `default` set, use that for existing rows. Else if 
> they have `null=True`, set existing rows to `NULL`. Else, set existing rows 
> to empty string.
>
> See linked rant/ticket for some (hopefully) compelling arguments..
>
> Thoughts?
>

-- 
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/aa6b4b3a-cc82-410d-99e5-066655daba77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging config tries too hard

[Claude Paroz]

Le vendredi 9 septembre 2016 07:31:42 UTC+2, Ivan Sagalaev a écrit : 

> I think the best end result would be one where LOGGING simply defines the 
>> full config and it is always applied (by Django) exactly once, and the 
>> defaults we want are set as the global default for LOGGING, and just 
>> documented so that people who want to set LOGGING themselves can easily 
>> copy them as a starting point.
>>
>
> I'm actually for that, too. And the defaults should live in 
> global_settings.py, not hard-coded in utils/log.py
>
> Funny, it was exactly like that before it's been changed to the current 
> way in 1.5 :-)
>

As the committer of the current implementation, I must admit I was probably 
not aware of the weird behavior of disable_existing_loggers at the time.
The main drawback of the proposed solution is that each time we change the 
default LOGGING config, people with custom LOGGING will have to look at a 
diff of the change and manually merge the interesting parts in their custom 
config (hoping that they are reading the full release notes!). But I'm not 
sure there's a better solution.

Claude

-- 
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/97641cbe-77c7-4aa7-b1df-22ce79ba5c62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Migration Questioner and String-Type Fields

[Jarek Glowacki]

I made a rant/ticket regarding the hidden usage of `blank` here: #27197 
.

In short, I don't think that `blank` should dictate whether or not the 
migration questioner runs.
Building on this, I don't think it should run for for string-type fields at 
all. If they have `default` set, use that for existing rows. Else if they 
have `null=True`, set existing rows to `NULL`. Else, set existing rows to 
empty string.

See linked rant/ticket for some (hopefully) compelling arguments..

Thoughts?

-- 
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/4020975e-b732-4828-ba32-b2d0cb3ee408%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.