django.channels: "async" for Django

[Andrew Godwin]

Hello everyone,

I've been formulating a plan to decouple Django from the request-response
cycle for a couple of years now and after discussing it with some people at
DjangoCon Europe I thought it was high time that I actually wrote it up,
wrote some code, and solicited feedback.

So here it is. The proposal is very long, and is in a Gist here:
https://gist.github.com/andrewgodwin/b3f826a879eb84a70625

As a top-level summary:

 - Fully backwards-compatible
 - No actual "in-process" async like asyncio/greenlets (apart from a couple
of optional "interface server" modules where you can pick your async
implementation)
 - New base unit of Django work is no longer the view, it is the channel
consumer
 - Supports WebSockets, long-polling, offsetting complex tasks outside
views and more
 - Code looks and works the same - since it'll be a worker model, there's
no need to retrofit any core Django APIs for async stuff.

To help write the proposal and also to help you understand it, I've
semi-implemented the proposal over here as a third-party app:
https://github.com/andrewgodwin/django-channels

While the goal is to merge this into Django proper, prototyping and
iterating outside is much faster and more accessible for everyone involved,
and the goal is to get it working on 1.7 and 1.8 (currently only 1.8).

The basic chat example in the README of that project is up and running on
this code (and the Redis channel backend) here:
http://www.aeracode.org/chat/

Any and all feedback is welcomed, in this thread is probably best. This is
by no means a final plan, but I hope it will lead us towards something that
will make Django much more suitable for a modern Web.

(I'm about to get on a long flight to Tokyo, so I may not be immediately
responsive! And my example might crash, it's only running the websocket
server in screen!)

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

Re: 1.9 release planning

[Josh Smeaton]

I really like Ryan's second proposal (quoting here again):

2.2 - 0 mos - (LTS) No features dropped 
> *3.0 - 8 mos - All deprecations, including the LTS deprecations, are 
> removed *
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> *4.0 - 32 mos - All deprecations, including the LTS deprecations, are 
> removed *
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped


It'll mean that the maximum time a feature can be supported while 
deprecating is 2 years. The shortest it can be supported is a single 
release if the deprecation is made in an LTS - which I think is fine 
because the LTS is supported for 3 years anyway. It perfectly adheres to 
semver (which is a nice property, but not the be-all and end-all), and 
still allows libraries to straddle two LTS releases. Is there a good reason 
we couldn't use this model?

And I agree with Tim that changing the version numbers of already planned 
releases is not a good idea. The version naming can wait until the current 
Removed* warnings are gone - and timing it with the Python 3 only release 
sounds like a fairly good motivation to bump the major version and continue 
with semver from there. Provided we remember/document the plan :)

On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
>
> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs 
> reference Django 1.9. I'm not enthusiastic about updating all that.
>
> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>>
>>
>> > On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
>> > 
>> > I don't have a strong opinion either way on semver, but I think it's a 
>> bit late to rebrand 1.9 as 2.0 considering we've release code and docs with 
>> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
>> We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
>> with the cutover to Python 3. 
>>
>>
>> Currently we have: 
>>
>> 1.8: 
>> RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
>> RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations 
>> from 1.8 
>>
>> master: 
>> RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
>> RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations 
>> from master 
>>
>> In any case, implementing the new policy will require updating warnings 
>> from master: RemovedInDjango21Warning needs to become either 
>> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
>> SemVer. 
>>
>> The question is whether it's too invasive to update warnings in a 1.8 
>> patch release. If we ensure that RemovedInDjango19Warning remains 
>> importable by aliasing it to RemovedInDjango20Warning(DeprecationWarning), 
>> I think it's compatible enough not to delay implementing the scheme by 
>> another two years, especially considering how warnings are normally used. 
>> But if we want to be super cautious we could just leave the code as it is 
>> and document the problem in the 1.8 release notes, after all we are 
>> extending the lifespan of the shims (at least in appearance) which isn't as 
>> problematic as if we were shortening it. 
>>
>> -- 
>> Loïc 
>>
>>

-- 
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/4c636d6d-4365-48dc-932a-5a67cec44a51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how long to support Python 3.3?

[Tim Graham]

Here are the cleanups for dropping Python 3.3: 
https://github.com/django/django/pull/4861

To prevent users from getting stuck on a non-LTS version of Django with an 
old version of Python (when they would have had longer support had they 
stuck with an LTS), the policy I suggest we adopt is:

Typically, we will support a Python version up to and including the first
Django LTS release that will receive security updates until after security
support for that version of Python ends. For example, Python 3.3 security
support ends September 2017 and Django 1.8 LTS security support ends April
2018. Therefore Django 1.8 is the last version to support Python 3.3.

On Sunday, June 14, 2015 at 10:55:42 AM UTC-4, Collin Anderson wrote:
>
> Some more data points (to support removing 3.3 support):
>
> I believe old versions of RHEL were the reason people needed 2.6 support. 
> Unlike 2.6, I believe RHEL has never supported Python 3 except through 
> "Software Collections", and the Python33 software collection EOL is Oct 
> 2016 (before 1.8 support ends). There is also now a Python 3.4 software 
> collection.
> https://access.redhat.com/support/policy/updates/rhscl
>
> Looking at recent PyPI data gathered by Donald: 
> https://caremad.io/2015/04/a-year-of-pypi-downloads/
> It looks like 3.3 has less usage than Python2.6 in the Django world.
>
> https://caremad.io/images/a-year-of-pypi-downloads/django-stacked-py-pct.png
> (It also looks like 3.x usage has more than doubled over the last year. :)
>
> On Saturday, June 13, 2015 at 7:00:55 PM UTC-4, Tim Graham wrote:
>>
>> Django 1.8 was the last version to support Python 3.2, which has its 
>> security updates end February 2016. That means Python 3.2 users can 
>> continue getting Django security updates for about 2 years after Python 
>> security updates end. I am wondering if we should instead try to better 
>> align the end of Python support with the end of Django support? (By the 
>> way, Django 1.4 supports Python 2.5 which had its security updates end Oct 
>> 2011 and since we had trouble configuring Jenkins with Python 2.5, we broke 
>> compatibility a couple times in recent security releases -- now I run the 
>> tests locally as needed).
>>
>> Let's take Python 3.3 as an example. Security updates for Python 3.3 are 
>> scheduled to end in September 2017. Django 1.8 supports 3.3 and will 
>> receive updates until April 2018. Given anyone using 3.3 is covered by the 
>> LTS, I'm inclined to drop 3.3 support now (in Django 1.9). Alternatively, 
>> the next two major releases of Django will be supported until April 2017 
>> and December 2017. 
>>
>> I don't find Django support for 3.3 to be a big burden, but there are 
>> occasional issues such as new features in 3.4 that are missing and need to 
>> be backported for 3.3 (today I ran into a pull request with a need for 
>> glob.escape(), so we needed a backport that works on Python 2 and Python 
>> 3.3). The other consideration is that Python 3.5 will be released in 
>> September, so we'd be back to 3 versions of Python 3 for Jenkins to test 
>> against.
>>
>> Are there any users of Python 3.3 out there who find that there are big 
>> obstacles to upgrading to 3.4?
>>
>> I think it's useful to plan ahead a bit to try to avoid cases such as the 
>> enterprise users who are now stuck on Python 2.6 and Django 1.6.
>>
>

-- 
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/2cb3280b-c580-4950-a5bf-a25e0c7a5034%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Loïc Bistuer]

I'm -0 (borderline -1) on that proposal. I don't think we should compromise on 
our historical commitment of deprecating over 2 releases, especially since it's 
aligned with the policy of Python itself and much of the ecosystem.

It should be as easy as possible for 3rd-party apps to straddle 2 LTS releases, 
but when it comes to user projects we should make it as easy as possible to 
keep up with the latest stable. Sticking to LTS versions deprive you from up to 
three years of innovation in Django, IMO it's only appropriate for projects in 
maintenance mode. Our current policy allows you to take advantage of new 
features right away while having almost a year and a half to deal with 
deprecations.

The only additional overhead of my counterproposal is an extra 8 months of 
support for features deprecated in an LTS for a total of 16 months. Considering 
non-LTS releases require between 16 months and 24 months I think it's very 
manageable.

Regarding timeline for adoption, I prefer switching right away but I'm also 
happy with a 2.1 > 3.0 switch, so whatever is more popular. Also it shouldn't 
get lost because regardless of the SemVer decision we'll need to update 
RemovedInDjango21Warning in master.

> On Jun 15, 2015, at 19:37, Josh Smeaton  wrote:
> 
> I really like Ryan's second proposal (quoting here again):
> 
> 2.2 - 0 mos - (LTS) No features dropped 
> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed 
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed 
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped
> 
> It'll mean that the maximum time a feature can be supported while deprecating 
> is 2 years. The shortest it can be supported is a single release if the 
> deprecation is made in an LTS - which I think is fine because the LTS is 
> supported for 3 years anyway. It perfectly adheres to semver (which is a nice 
> property, but not the be-all and end-all), and still allows libraries to 
> straddle two LTS releases. Is there a good reason we couldn't use this model?
> 
> And I agree with Tim that changing the version numbers of already planned 
> releases is not a good idea. The version naming can wait until the current 
> Removed* warnings are gone - and timing it with the Python 3 only release 
> sounds like a fairly good motivation to bump the major version and continue 
> with semver from there. Provided we remember/document the plan :)
> 
> On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs reference 
> Django 1.9. I'm not enthusiastic about updating all that.
> 
> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
> 
> > On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
> > 
> > I don't have a strong opinion either way on semver, but I think it's a bit 
> > late to rebrand 1.9 as 2.0 considering we've release code and docs with 
> > reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
> > We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
> > with the cutover to Python 3. 
> 
> 
> Currently we have: 
> 
> 1.8: 
> RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
> RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 
> 1.8 
> 
> master: 
> RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
> RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from 
> master 
> 
> In any case, implementing the new policy will require updating warnings from 
> master: RemovedInDjango21Warning needs to become either 
> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
> SemVer. 
> 
> The question is whether it's too invasive to update warnings in a 1.8 patch 
> release. If we ensure that RemovedInDjango19Warning remains importable by 
> aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's 
> compatible enough not to delay implementing the scheme by another two years, 
> especially considering how warnings are normally used. But if we want to be 
> super cautious we could just leave the code as it is and document the problem 
> in the 1.8 release notes, after all we are extending the lifespan of the 
> shims (at least in appearance) which isn't as problematic as if we were 
> shortening it. 
> 
> -- 
> Loïc 
> 
> 
> -- 
> 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 
> http

Re: 1.9 release planning

[Ryan Hiebert]

Given the negative reaction to quick deprecation of LTS releases, I also now 
most prefer Loïc's proposal. It's semver with a little extra to help folks out.

I'd also most prefer seeing 1.9 being changed to 2.0 if this proposal were 
accepted, but that is not a strong opinion given that I am not familiar with 
the pain involved with renaming the deprecation warnings.

Sent from my iPhone

> On Jun 15, 2015, at 08:54, Loïc Bistuer  wrote:
> 
> I'm -0 (borderline -1) on that proposal. I don't think we should compromise 
> on our historical commitment of deprecating over 2 releases, especially since 
> it's aligned with the policy of Python itself and much of the ecosystem.
> 
> It should be as easy as possible for 3rd-party apps to straddle 2 LTS 
> releases, but when it comes to user projects we should make it as easy as 
> possible to keep up with the latest stable. Sticking to LTS versions deprive 
> you from up to three years of innovation in Django, IMO it's only appropriate 
> for projects in maintenance mode. Our current policy allows you to take 
> advantage of new features right away while having almost a year and a half to 
> deal with deprecations.
> 
> The only additional overhead of my counterproposal is an extra 8 months of 
> support for features deprecated in an LTS for a total of 16 months. 
> Considering non-LTS releases require between 16 months and 24 months I think 
> it's very manageable.
> 
> Regarding timeline for adoption, I prefer switching right away but I'm also 
> happy with a 2.1 > 3.0 switch, so whatever is more popular. Also it shouldn't 
> get lost because regardless of the SemVer decision we'll need to update 
> RemovedInDjango21Warning in master.
> 
>> On Jun 15, 2015, at 19:37, Josh Smeaton  wrote:
>> 
>> I really like Ryan's second proposal (quoting here again):
>> 
>> 2.2 - 0 mos - (LTS) No features dropped 
>> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed 
>> 3.1 - 16 mos - No features dropped 
>> 3.2 - 24 mos - (LTS) No features dropped 
>> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed 
>> 4.1 - 40 mos - No features dropped 
>> 4.2 - 48 mos - (LTS) No features dropped
>> 
>> It'll mean that the maximum time a feature can be supported while 
>> deprecating is 2 years. The shortest it can be supported is a single release 
>> if the deprecation is made in an LTS - which I think is fine because the LTS 
>> is supported for 3 years anyway. It perfectly adheres to semver (which is a 
>> nice property, but not the be-all and end-all), and still allows libraries 
>> to straddle two LTS releases. Is there a good reason we couldn't use this 
>> model?
>> 
>> And I agree with Tim that changing the version numbers of already planned 
>> releases is not a good idea. The version naming can wait until the current 
>> Removed* warnings are gone - and timing it with the Python 3 only release 
>> sounds like a fairly good motivation to bump the major version and continue 
>> with semver from there. Provided we remember/document the plan :)
>> 
>> On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
>> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs 
>> reference Django 1.9. I'm not enthusiastic about updating all that.
>> 
>>> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>>> 
>>> On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
>>> 
>>> I don't have a strong opinion either way on semver, but I think it's a bit 
>>> late to rebrand 1.9 as 2.0 considering we've release code and docs with 
>>> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
>>> We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
>>> with the cutover to Python 3.
>> 
>> 
>> Currently we have: 
>> 
>> 1.8: 
>>RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
>>RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 
>> 1.8 
>> 
>> master: 
>>RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
>>RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from 
>> master 
>> 
>> In any case, implementing the new policy will require updating warnings from 
>> master: RemovedInDjango21Warning needs to become either 
>> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
>> SemVer. 
>> 
>> The question is whether it's too invasive to update warnings in a 1.8 patch 
>> release. If we ensure that RemovedInDjango19Warning remains importable by 
>> aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's 
>> compatible enough not to delay implementing the scheme by another two years, 
>> especially considering how warnings are normally used. But if we want to be 
>> super cautious we could just leave the code as it is and document the 
>> problem in the 1.8 release notes, after all we are extending the lifespan of 
>> the shims (at least in appearance) which isn't 

Re: django.channels: "async" for Django

[BearXu]

Personally I don't agree with implementing the Channel using in-memory mode
first. Writing code to communicate among  sockets will become very
difficult for me(ordinary developer). If we see async in Django as a tool
instead of a coding style, I think Redis/NoSql/Database backend/ is good
enough as a first step.

On 15 June 2015 at 03:25, Andrew Godwin  wrote:

> Hello everyone,
>
> I've been formulating a plan to decouple Django from the request-response
> cycle for a couple of years now and after discussing it with some people at
> DjangoCon Europe I thought it was high time that I actually wrote it up,
> wrote some code, and solicited feedback.
>
> So here it is. The proposal is very long, and is in a Gist here:
> https://gist.github.com/andrewgodwin/b3f826a879eb84a70625
>
> As a top-level summary:
>
>  - Fully backwards-compatible
>  - No actual "in-process" async like asyncio/greenlets (apart from a
> couple of optional "interface server" modules where you can pick your async
> implementation)
>  - New base unit of Django work is no longer the view, it is the channel
> consumer
>  - Supports WebSockets, long-polling, offsetting complex tasks outside
> views and more
>  - Code looks and works the same - since it'll be a worker model, there's
> no need to retrofit any core Django APIs for async stuff.
>
> To help write the proposal and also to help you understand it, I've
> semi-implemented the proposal over here as a third-party app:
> https://github.com/andrewgodwin/django-channels
>
> While the goal is to merge this into Django proper, prototyping and
> iterating outside is much faster and more accessible for everyone involved,
> and the goal is to get it working on 1.7 and 1.8 (currently only 1.8).
>
> The basic chat example in the README of that project is up and running on
> this code (and the Redis channel backend) here:
> http://www.aeracode.org/chat/
>
> Any and all feedback is welcomed, in this thread is probably best. This is
> by no means a final plan, but I hope it will lead us towards something that
> will make Django much more suitable for a modern Web.
>
> (I'm about to get on a long flight to Tokyo, so I may not be immediately
> responsive! And my example might crash, it's only running the websocket
> server in screen!)
>
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1upKYO7MxyuRigYphJfCqqj%2BKPp_uhBgymEK2oMtP%2BJMPA%40mail.gmail.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/CAB%2B2MZygJ10J8_bPFkE8AR%3D1mQ%3D0KKWWvXvoHhnmKaVJzZFBGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django Admin - list_display default value

[Rick van Hattem (wolph)]

While there are several solutions to this problem, I find myself 
scaffolding the Django admin every time I create a new app/model. I even 
created an app to do just that (harmless 
plug: https://pypi.python.org/pypi/django-admin-generator/).

Anyhow... I've wondered for some time why Django doesn't just default to 
all local fields for "list_display", it would make the admin far easier to 
read by default and anyone doing specific things can easily override it 
anyhow. It would definitely save me a lot of repetition and if it's only 
local fields (no foreignkeys or m2m stuff) I don't really see the harm in 
it either.

Would anyone oppose a pull request like this?


-- 
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/b8ecd931-da10-48f6-8117-d1a9228e939d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request: initialize fields with built-in class defaults

[Rick van Hattem (wolph)]

While I understand the rationale, it's not really possible due to the 
underlying Python object:
>>> import datetime
>>> datetime.date()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: Required argument 'year' (pos 1) not found
>>> datetime.datetime()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: Required argument 'year' (pos 1) not found

Note that you can easily support it by having something like this:

class Question(models.Model):
 pub_date = models.DateField(default=datetime.date.today, blank=True)




~wolph

On Monday, June 15, 2015 at 7:52:13 AM UTC+2, Bobby Mozumder wrote:
>
> Hi all,
>
> Here’s an issue of usability that if fixed could make usage of custom 
> fields simpler.
>
> Right now fields don’t allow a built-in defaults, and you need to 
> explicitly set the default parameter for model fields.  The problem is 
> that this adds a ton of boilerplate code.
>
> Using the Polls tutorial example, if I do:
>
> >>> from polls.models import Question, Choice
> >>> q = Question()
>
> By default it’s always :
>
> >>> type(q.pub_date)
> 
>
> The pub_date should always be a type .  If 
> this was defined in the model constructor, then we could start to access 
> the datetime.datetime class immediately, to assign data.  If I had a 
> custom datetime.datetime class, I could possibly do this immediately:
>
> >>> q = Question()
> >>> q.pub_date.month = 11
> >>> q.pub_date.day = 26
> >>> q.pub_date.year = 2016
> >>> q.save()
>
> But right it would give the following error:
>
> >>> q.pub_date.year = 2016
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'NoneType' object has no attribute 'year'
>
> Is this a reasonable request?  
>
> I’m able to do something like this now with my own custom fields that 
> derive from models.SubfieldBase, but that class is deprecated, and the 
> new 1.8 model initializer doesn’t do this anymore.
>
> Thank you,
>
> -bobby
>

-- 
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/43d136dd-b8d7-45fe-91af-1863cb5aa205%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - list_display default value

[Florian Apolloner]

On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph) wrote:
>
> Would anyone oppose a pull request like this?
>

Yes, it is highly backwards incompatible for not much gain, I am also 
usually just fine with one/two fields for list_display. You could just use 
your own admin subclass for 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-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/51bfde69-dcf3-4006-93c4-601a1ce037fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Aymeric Augustin]

Le 15 juin 2015 à 15:54, Loïc Bistuer  a écrit :
> 
> I'm -0 (borderline -1) on that proposal. I don't think we should compromise 
> on our historical commitment of deprecating over 2 releases

I'm in the same camp as Loïc on this specific point.

If we're approaching consensus, could a kind soul put together a final proposal 
and submit it to the technical board, along with the main arguments or 
alternatives? I'm finding it difficult to follow this 50-message thread... 
Thanks :-)

-- 
Aymeric.

-- 
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/1A9872EF-5D1A-4621-972B-F657C076D272%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

[no subject]

[Rick van Hattem]

On 15 June 2015 at 21:34, Florian Apolloner  wrote:

>
>
> On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> wrote:
>>
>> Would anyone oppose a pull request like this?
>>
>
> Yes, it is highly backwards incompatible for not much gain, I am also
> usually just fine with one/two fields for list_display. You could just use
> your own admin subclass for that.
>

Can you clarify on that? I don't see the backwards incompatibility here.

Upgrading or downgrading Django won't break this in any way and it won't
change the way people can override the list_display default value so by
definition it's not breaking either forwards or backwards compatibility. It
changes behaviour and looks, but it doesn't break anything.

The discussion here shouldn't be whether you can or cannot fix it yourself
(obviously, you can, that's not the issue), it's what a good/sane default
would be. For brand new Django users, would it be more convenient to have 1
column or just all local columns and make it slightly more usable?

~wolph

-- 
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/CAJAwA%3Dz08kMH9Wv_iANf-byofidSEsEhN5eqdVA63NJvAMFtBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - list_display default value

[Shai Berger]

(I received the message I'm replying to here with an empty subject, and 
detached from the thread. Google Groups being funny?)

On Monday 15 June 2015 22:52:09 Rick van Hattem wrote:
> On 15 June 2015 at 21:34, Florian Apolloner  wrote:
> > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> > 
> > wrote:
> >> Would anyone oppose a pull request like this?
> > 
> > Yes, it is highly backwards incompatible for not much gain, I am also
> > usually just fine with one/two fields for list_display. You could just
> > use your own admin subclass for that.
> 
> Can you clarify on that? I don't see the backwards incompatibility here.
> 

It could quite easily cause breakage for specific client-side code, although I 
wouldn't consider that "highly" incompatible.

However, it could also easily lead to inappropriate data exposure -- where 
people who are supposed to get an "opaque" view of some objects will, upon 
upgrade, be able to see all their details. I consider that risk to weigh much 
more than the potential gains.
> 
> The discussion here shouldn't be whether you can or cannot fix it yourself
> (obviously, you can, that's not the issue), it's what a good/sane default
> would be. For brand new Django users, would it be more convenient to have 1
> column or just all local columns and make it slightly more usable?
> 
Beside "convenient", you should also consider "safe", and besides brand new 
users, there are also established users with significant codebases. Now, 
arguably, if we were starting the Django project today, we could use the 
default you propose, people would be aware of it, and if they wanted to limit 
access, they would. One could still argue that "whitelisting" is better than 
"blacklisting", and we could have a whole discussion about this. But having a 
Django upgrade just expose more data by default, even in the Admin, would be a 
serious breach of our users' trust IMO.

Shai.

Re: 1.9 release planning

[Tim Graham]

The Google doc has been evolving: 
https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing

On Monday, June 15, 2015 at 3:37:16 PM UTC-4, Aymeric Augustin wrote:
>
> Le 15 juin 2015 à 15:54, Loïc Bistuer > 
> a écrit : 
> > 
> > I'm -0 (borderline -1) on that proposal. I don't think we should 
> compromise on our historical commitment of deprecating over 2 releases 
>
> I'm in the same camp as Loïc on this specific point. 
>
> If we're approaching consensus, could a kind soul put together a final 
> proposal and submit it to the technical board, along with the main 
> arguments or alternatives? I'm finding it difficult to follow this 
> 50-message thread... Thanks :-) 
>
> -- 
> Aymeric.

-- 
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/dd4b36ba-baae-4e8a-a9f8-322f4af08eaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin - list_display default value

[Marc Tamlyn]

Agree this is not an appropriate default, although I could see an argument
for supporting __all__ like in forms. This isn't very hard as a third party
solution though so I'm not super keen on that idea.

M
On 15 Jun 2015 22:03, "Shai Berger"  wrote:

> (I received the message I'm replying to here with an empty subject, and
> detached from the thread. Google Groups being funny?)
>
> On Monday 15 June 2015 22:52:09 Rick van Hattem wrote:
> > On 15 June 2015 at 21:34, Florian Apolloner 
> wrote:
> > > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph)
> > >
> > > wrote:
> > >> Would anyone oppose a pull request like this?
> > >
> > > Yes, it is highly backwards incompatible for not much gain, I am also
> > > usually just fine with one/two fields for list_display. You could just
> > > use your own admin subclass for that.
> >
> > Can you clarify on that? I don't see the backwards incompatibility here.
> >
>
> It could quite easily cause breakage for specific client-side code,
> although I
> wouldn't consider that "highly" incompatible.
>
> However, it could also easily lead to inappropriate data exposure -- where
> people who are supposed to get an "opaque" view of some objects will, upon
> upgrade, be able to see all their details. I consider that risk to weigh
> much
> more than the potential gains.
> >
> > The discussion here shouldn't be whether you can or cannot fix it
> yourself
> > (obviously, you can, that's not the issue), it's what a good/sane default
> > would be. For brand new Django users, would it be more convenient to
> have 1
> > column or just all local columns and make it slightly more usable?
> >
> Beside "convenient", you should also consider "safe", and besides brand new
> users, there are also established users with significant codebases. Now,
> arguably, if we were starting the Django project today, we could use the
> default you propose, people would be aware of it, and if they wanted to
> limit
> access, they would. One could still argue that "whitelisting" is better
> than
> "blacklisting", and we could have a whole discussion about this. But
> having a
> Django upgrade just expose more data by default, even in the Admin, would
> be a
> serious breach of our users' trust IMO.
>
> Shai.
>

-- 
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/CAMwjO1HhkaHEGL%2BQaPc3_43%3DBJP84%2B-4XZMVs%3DK%2Bx8u6Q7c_Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request: initialize fields with built-in class defaults

[Bobby Mozumder]

> On Jun 15, 2015, at 1:42 PM, Rick van Hattem (wolph)  
> wrote:
> 
> While I understand the rationale, it's not really possible due to the 
> underlying Python object:
> >>> import datetime
> >>> datetime.date()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: Required argument 'year' (pos 1) not found
> >>> datetime.datetime()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: Required argument 'year' (pos 1) not found
> 

A custom Django field would either assign initial values to classes that need 
it, or use classes that have their own initial values.  The point is that the 
class itself should always exist in the field.

> Note that you can easily support it by having something like this:
> 
> class Question(models.Model):
>  pub_date = models.DateField(default=datetime.date.today, blank=True)
> 
> 

Right.  I’m trying to avoid this situation, as this adds a lot of code - I have 
dozens of custom fields instantiated hundreds of times in an app, with a lot of 
initialization data each.  It also requires the knowledge of which internal 
class that the field uses.  So, I have a common get/set interface for each 
custom field, so I don’t need to know which class that a field uses, as long as 
I interface with it properly.

-bobby

> 
> ~wolph
> 
> On Monday, June 15, 2015 at 7:52:13 AM UTC+2, Bobby Mozumder wrote:
> Hi all,
> 
> Here’s an issue of usability that if fixed could make usage of custom fields 
> simpler.
> 
> Right now fields don’t allow a built-in defaults, and you need to explicitly 
> set the default parameter for model fields.  The problem is that this adds a 
> ton of boilerplate code.
> 
> Using the Polls tutorial example, if I do:
> 
> >>> from polls.models import Question, Choice
> >>> q = Question()
> 
> By default it’s always :
> 
> >>> type(q.pub_date)
> 
> 
> The pub_date should always be a type .  If this 
> was defined in the model constructor, then we could start to access the 
> datetime.datetime class immediately, to assign data.  If I had a custom 
> datetime.datetime class, I could possibly do this immediately:
> 
> >>> q = Question()
> >>> q.pub_date.month = 11
> >>> q.pub_date.day = 26
> >>> q.pub_date.year = 2016
> >>> q.save()
> 
> But right it would give the following error:
> 
> >>> q.pub_date.year = 2016
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'NoneType' object has no attribute 'year'
> 
> Is this a reasonable request?  
> 
> I’m able to do something like this now with my own custom fields that derive 
> from models.SubfieldBase, but that class is deprecated, and the new 1.8 model 
> initializer doesn’t do this anymore.
> 
> Thank you,
> 
> -bobby
> 
> -- 
> 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/43d136dd-b8d7-45fe-91af-1863cb5aa205%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/CD62262A-302A-41F0-AF26-A1F34EC45D34%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request: initialize fields with built-in class defaults

[Shai Berger]

Hi Bobby,

I'm not sure what you mean by "fields don't allow built-in defaults". While 
it's true that Django's DateField (for example) doesn't have a built-in 
default, here's[1] a custom field with a built-in default:

class MyDateField(models.DateField):

EPOCH = date(1970, 1, 1)

def __init__(self, *args, **kw):
kw.setdefault('default', self.EPOCH)
super(MyDateField, self).__init__(*args, **kw)

I use kw.setdefault so that the default can still be overridden by the 
definition of a specific field.

Did you mean something else?

Shai.

[1] Caveat Lector: Untested code. I'd be quite surprised if it doesn't work.

On Tuesday 16 June 2015 01:18:07 Bobby Mozumder wrote:
> > On Jun 15, 2015, at 1:42 PM, Rick van Hattem (wolph) 
> > wrote:
> > 
> > While I understand the rationale, it's not really possible due to the 
underlying Python object:
> > >>> import datetime
> > >>> datetime.date()
> > 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > 
> > TypeError: Required argument 'year' (pos 1) not found
> > 
> > >>> datetime.datetime()
> > 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > 
> > TypeError: Required argument 'year' (pos 1) not found
> 
> A custom Django field would either assign initial values to classes that
> need it, or use classes that have their own initial values.  The point is
> that the class itself should always exist in the field.
> 
> > Note that you can easily support it by having something like this:
> > 
> > class Question(models.Model):
> >  pub_date = models.DateField(default=datetime.date.today, blank=True)
> 
> Right.  I’m trying to avoid this situation, as this adds a lot of code - I
> have dozens of custom fields instantiated hundreds of times in an app,
> with a lot of initialization data each.  It also requires the knowledge of
> which internal class that the field uses.  So, I have a common get/set
> interface for each custom field, so I don’t need to know which class that
> a field uses, as long as I interface with it properly.
> 
> -bobby
> 
> > ~wolph
> > 
> > On Monday, June 15, 2015 at 7:52:13 AM UTC+2, Bobby Mozumder wrote:
> > Hi all,
> > 
> > Here’s an issue of usability that if fixed could make usage of custom
> > fields simpler.
> > 
> > Right now fields don’t allow a built-in defaults, and you need to
> > explicitly set the default parameter for model fields.  The problem is
> > that this adds a ton of boilerplate code.
> > 
> > Using the Polls tutorial example, if I do:
> > >>> from polls.models import Question, Choice
> > >>> q = Question()
> > 
> > By default it’s always :
> > >>> type(q.pub_date)
> > 
> > 
> > 
> > The pub_date should always be a type .  If this 
was defined in the model constructor, then we could start to access the 
datetime.datetime class immediately, to assign data.  If I had a custom 
datetime.datetime class, I could possibly do this immediately:
> > >>> q = Question()
> > >>> q.pub_date.month = 11
> > >>> q.pub_date.day = 26
> > >>> q.pub_date.year = 2016
> > >>> q.save()
> > 
> > But right it would give the following error:
> > >>> q.pub_date.year = 2016
> > 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > 
> > AttributeError: 'NoneType' object has no attribute 'year'
> > 
> > Is this a reasonable request?
> > 
> > I’m able to do something like this now with my own custom fields that
> > derive from models.SubfieldBase, but that class is deprecated, and the
> > new 1.8 model initializer doesn’t do this anymore.
> > 
> > Thank you,
> > 
> > -bobby