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
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
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.
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
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
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
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
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
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:
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
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
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
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
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
On Tue, Sep 6, 2016, Patrick Heneghan wrote:
>It might help for me to explain this in context - for example, I'm going to
>have a "post type" called "blog", which should have title and content
>fields, and then "event", which should have additional location, date,
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
>>
16 matches
Mail list logo