Re: Adding UNION/INTERSECT/EXCEPT to the ORM

[charettes]

+1 to QuerySet.difference()

Le mercredi 11 janvier 2017 17:00:12 UTC-5, sebleier a écrit :
>
> We cannot use the name "QuerySet.except()" since except is a reserved word 
>> in Python. Do you prefer minus() (as suggested by Florian), except_() (as 
>> done by SQLAlchemy), or something else?
>>
>>
> Can I suggest using "QuerySet.difference"?   It's what python's sets use 
> for achieving the same functionality.
>
> On Monday, December 26, 2016 at 6:28:15 PM UTC-5, Adam Johnson wrote:
>>>
>>> Yes it's different, they cannot be changed due to backwards 
>>> compatibility issues. They don't result in UNION in SQL, they union the 
>>> filters on two querysets that are on the same exact model.
>>>
>>> On 26 December 2016 at 21:00, Cristiano Coelho  
>>> wrote:
>>>
 Is this going to be different from the pipe ( | ) and and ( & ) 
 operators on querysets? If I'm not wrong those can already result in a 
 union query (but not necessary, sometimes it just returns a query with an 
 or/and condition)


 El viernes, 23 de diciembre de 2016, 11:12:40 (UTC-3), Florian 
 Apolloner escribió:
>
> Hi,
>
> I have a currently WIP PR at 
> https://github.com/django/django/pull/7727
>
> The usage is currently something like this:
>
> qs1 = User.objects.all().values('username')
> qs2 = Group.objects.all().values('name')
> results = qs1.union(qs).distinct().order_by('name')[:10]
>
> (order_by does not work though yet)
>
> So far I have a few questions:
>
>  * Should .union/.intersect etc return a new type of queryset or stay 
> with the base QuerySet class (probably less code duplication)
>  * We currently have a few methods which check can_filter and error 
> out accordingly (ie you cannot filter after slicing), but as the error 
> message in 
> https://github.com/django/django/blob/master/django/db/models/query.py#L579
>  
> shows, this strongly relies on knowledge of the implementation of the 
> filter. For combined querysets I basically need to limit everything aside 
> from order by and limit/offset. Would a method like this make some sense 
> (on the Query class):
>
> def is_allowed(self, action):
>   if self.combinatorial and action not in ('set_operation', 
> 'order_by', 'slicing'):
> raise SomeError('Cannot use this method on an combinatorial 
> queryset')
>   elif action == 'filter' and (self.low_mark or self.high_mark):
> raise SomeError('Cannot filter after slicing')
>
>  * set_operator in base.py feels a bit weird (
> https://github.com/django/django/pull/7727/files#diff-53fcf3ac0535307033e0cfabb85c5301)
>  
> -- any better options?
>  * How can I change the generated order_by clause to reference the 
> columns "unqualified" (ie without table name), can I somehow just realias 
> every column? 
>
> Cheers,
> Florian
>
 -- 
 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/d38358ca-c97f-4bb0-a390-e38f3b4b8f6c%40googlegroups.com
  
 
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Adam
>>>
>> -- 
>> 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/3084faa0-e097-4227-9a34-f870c8be6809%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 

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

[Sean Bleier]

>
> We cannot use the name "QuerySet.except()" since except is a reserved word
> in Python. Do you prefer minus() (as suggested by Florian), except_() (as
> done by SQLAlchemy), or something else?
>
>
Can I suggest using "QuerySet.difference"?   It's what python's sets use
for achieving the same functionality.

On Monday, December 26, 2016 at 6:28:15 PM UTC-5, Adam Johnson wrote:
>>
>> Yes it's different, they cannot be changed due to backwards compatibility
>> issues. They don't result in UNION in SQL, they union the filters on two
>> querysets that are on the same exact model.
>>
>> On 26 December 2016 at 21:00, Cristiano Coelho 
>> wrote:
>>
>>> Is this going to be different from the pipe ( | ) and and ( & )
>>> operators on querysets? If I'm not wrong those can already result in a
>>> union query (but not necessary, sometimes it just returns a query with an
>>> or/and condition)
>>>
>>>
>>> El viernes, 23 de diciembre de 2016, 11:12:40 (UTC-3), Florian Apolloner
>>> escribió:

 Hi,

 I have a currently WIP PR at https://github.com/django/django/pull/7727

 The usage is currently something like this:

 qs1 = User.objects.all().values('username')
 qs2 = Group.objects.all().values('name')
 results = qs1.union(qs).distinct().order_by('name')[:10]

 (order_by does not work though yet)

 So far I have a few questions:

  * Should .union/.intersect etc return a new type of queryset or stay
 with the base QuerySet class (probably less code duplication)
  * We currently have a few methods which check can_filter and error out
 accordingly (ie you cannot filter after slicing), but as the error message
 in https://github.com/django/django/blob/master/django/db/model
 s/query.py#L579 shows, this strongly relies on knowledge of the
 implementation of the filter. For combined querysets I basically need to
 limit everything aside from order by and limit/offset. Would a method like
 this make some sense (on the Query class):

 def is_allowed(self, action):
   if self.combinatorial and action not in ('set_operation', 'order_by',
 'slicing'):
 raise SomeError('Cannot use this method on an combinatorial
 queryset')
   elif action == 'filter' and (self.low_mark or self.high_mark):
 raise SomeError('Cannot filter after slicing')

  * set_operator in base.py feels a bit weird (
 https://github.com/django/django/pull/7727/files#diff-53fcf
 3ac0535307033e0cfabb85c5301) -- any better options?
  * How can I change the generated order_by clause to reference the
 columns "unqualified" (ie without table name), can I somehow just realias
 every column?

 Cheers,
 Florian

>>> --
>>> 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
>>> gid/django-developers/d38358ca-c97f-4bb0-a390-e38f3b4b8f6c%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> 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/3084faa0-e097-4227-9a34-
> f870c8be6809%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 

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

[Tim Graham]

We cannot use the name "QuerySet.except()" since except is a reserved word 
in Python. Do you prefer minus() (as suggested by Florian), except_() (as 
done by SQLAlchemy), or something else?

On Monday, December 26, 2016 at 6:28:15 PM UTC-5, Adam Johnson wrote:
>
> Yes it's different, they cannot be changed due to backwards compatibility 
> issues. They don't result in UNION in SQL, they union the filters on two 
> querysets that are on the same exact model.
>
> On 26 December 2016 at 21:00, Cristiano Coelho  > wrote:
>
>> Is this going to be different from the pipe ( | ) and and ( & ) operators 
>> on querysets? If I'm not wrong those can already result in a union query 
>> (but not necessary, sometimes it just returns a query with an or/and 
>> condition)
>>
>>
>> El viernes, 23 de diciembre de 2016, 11:12:40 (UTC-3), Florian Apolloner 
>> escribió:
>>>
>>> Hi,
>>>
>>> I have a currently WIP PR at https://github.com/django/django/pull/7727
>>>
>>> The usage is currently something like this:
>>>
>>> qs1 = User.objects.all().values('username')
>>> qs2 = Group.objects.all().values('name')
>>> results = qs1.union(qs).distinct().order_by('name')[:10]
>>>
>>> (order_by does not work though yet)
>>>
>>> So far I have a few questions:
>>>
>>>  * Should .union/.intersect etc return a new type of queryset or stay 
>>> with the base QuerySet class (probably less code duplication)
>>>  * We currently have a few methods which check can_filter and error out 
>>> accordingly (ie you cannot filter after slicing), but as the error message 
>>> in 
>>> https://github.com/django/django/blob/master/django/db/models/query.py#L579 
>>> shows, this strongly relies on knowledge of the implementation of the 
>>> filter. For combined querysets I basically need to limit everything aside 
>>> from order by and limit/offset. Would a method like this make some sense 
>>> (on the Query class):
>>>
>>> def is_allowed(self, action):
>>>   if self.combinatorial and action not in ('set_operation', 'order_by', 
>>> 'slicing'):
>>> raise SomeError('Cannot use this method on an combinatorial 
>>> queryset')
>>>   elif action == 'filter' and (self.low_mark or self.high_mark):
>>> raise SomeError('Cannot filter after slicing')
>>>
>>>  * set_operator in base.py feels a bit weird (
>>> https://github.com/django/django/pull/7727/files#diff-53fcf3ac0535307033e0cfabb85c5301)
>>>  
>>> -- any better options?
>>>  * How can I change the generated order_by clause to reference the 
>>> columns "unqualified" (ie without table name), can I somehow just realias 
>>> every column? 
>>>
>>> Cheers,
>>> Florian
>>>
>> -- 
>> 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/d38358ca-c97f-4bb0-a390-e38f3b4b8f6c%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Adam
>

-- 
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/3084faa0-e097-4227-9a34-f870c8be6809%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to Integrate Django with Angular 2

[Asif Saifuddin]

This is not the place to ask such kind of questions, please post to 
django-users as this list is for discussing django internals.

On Thursday, January 12, 2017 at 1:08:29 AM UTC+6, Mohit Saran wrote:
>
> How to Integrate Django with Angular 2
>

-- 
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/37ee7bd4-fcd8-426b-a5f0-b0c3a621302e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

I agree. The question in my mind is how to pick an appropriate number of 
iterations that we don't risk causing a DoS on (at least most) existing 
sites due to increased CPU usage. Or at least, can we offer some 
suggestions about how to tell if your site receives sufficient traffic that 
you might be impacted? Did anyone notice increased CPU usage in past 
upgrades?

On Tuesday, January 10, 2017 at 1:27:19 PM UTC-5, Tobias McNulty wrote:
>
> IMO this doesn't change the argument that it would be best to default to 
> the higher number of iterations (i.e., 100k or higher, given some time as 
> passed since 2013), while noting in the documentation that individual 
> projects have the ability to reduce it if need be (though perhaps 
> recommending that they try first to find a faster Python). Other thoughts?
>
> On Mon, Jan 9, 2017 at 10:44 PM, Martin Koistinen  > wrote:
>
>> The Python3.5 on my system was installed by the official Python 
>> installer, and is almost 3X slower than the Apple-built 2.7 install. I use 
>> pip all day long.
>>
>> True, my MacBook is not a server, but it still serves to demonstrate the 
>> point that it is not a reasonable assumption that all 3.5 installs use 
>> OpenSSL libraries.
>>
>> On Monday, January 9, 2017 at 7:39:18 PM UTC-5, Tim Graham wrote:
>>>
>>> About "we cannot just assume that all Python 3 installs have a "fast" 
>>> PBKDF2 implementation" -- I'd expect very few if any Django users to be 
>>> compiling their own Python and doing so without OpenSSL. I'm guessing that 
>>> any operating system Python will have the OpenSSL bindings. Or is that a 
>>> bad assumption?
>>>
>>> On Wednesday, January 4, 2017 at 2:13:09 PM UTC-5, Martin Koistinen 
>>> wrote:

 I think this is a pretty solid guess. Bear in mind this was a direct 
 install from Python.org.

 The important thing here is, this demonstrates that we cannot just 
 assume that all Python 3 installs have a "fast" PBKDF2 implementation =/

 On Wednesday, January 4, 2017 at 11:33:17 AM UTC-5, Tobias McNulty 
 wrote:

> ... 
>
 Martin, is it possible your version of Python 3 is not linked against 
> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't 
> had 
> a chance to try your benchmark yet, but in a quick test I don't see any 
> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>
> Tobias
>

  

>>> -- 
>> 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/9261dcdc-f3b2-458c-a6e1-bde49642c56b%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com 
> www.caktusgroup.com
>

-- 
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/34fc63bf-9eff-4ecb-a931-3f25d69faddf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: changing the default MySQL isolation level to READ COMMITTED

[Patryk Zawadzki]

To add some context, REPEATABLE READ can break get_or_create among other 
things (not sure how many invalid tickets Django gets related to 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eeac7c52-78c6-4b9c-bf0a-1a96f5d0b432%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

changing the default MySQL isolation level to READ COMMITTED

[Tim Graham]

In ticket #27683 [0], Shai proposed to change Django to default to using 
the READ COMMITTED isolation level. Some background on the reasons are on 
the ticket and in another thread [1] (possible data loss is involved).

The initial approach [2] that Shai put forward is adding a deprecation 
warning and a system check:
- The deprecation warning says, "Django's default transaction isolation 
level on MySQL is going to change from REPEATABLE READ (MySQL's default) to 
READ COMMITTED. Specify an explicit level by setting 'isolation_level' in 
'OPTIONS' in the connection settings."
- The system check warning (visible when running migrate) says, 
"Transaction isolation level for database connection 'default' is 
'REPEATABLE-READ'. Django and many of its apps are written to work 
correctly under the READ COMMITTED transaction isolation level. MySQL's 
default level, REPEATABLE READ, may imply some surprising behaviors under 
concurrent loads, leading to possible data loss. It is recommended that you 
change the transaction isolation level."

If an isolation level isn't specified in DATABASES['OPTIONS'], Django would 
start setting a READ COMMITTED isolation level in Django 2.1. Both the 
system check (since it wouldn't trigger anymore) and the deprecation 
warning would be removed at that time. The reason for having both a check 
and a deprecation warning seems to be that deprecation warnings are silent 
by default.

An alternate idea is to skip the deprecation cycle and make Django start 
setting the default isolation in Django 1.11. I'm not sure if giving 
projects two release cycles to choose their isolation level adds value. In 
the "no thinking involved" case, it's not difficult to specify what's being 
used now, REPEATABLE READ. If Django changed the isolation level in 1.11, a 
"compatibility" system check could raise a warning if 'isolation_level' 
isn't specified in the database settings. This leaves projects in the same 
place as the first approach, where all MySQL projects have to specify an 
isolation level to silence a warning. That check would be removed in Django 
2.0, which avoids another 8 months of new MySQL projects (started with 
Django 2.0) having a check and/or deprecation warning out of the box that 
the first approach requires. (Ideally, the compatibility system check could 
differentiate between existing projects and new projects in Django 1.11, 
but past heuristics to do this involving examining settings and comparing 
them to the startproject defaults haven't been accurate.)

Shai said, "The deprecation period may be required because although the 
warnings and settings are at the project level, there may be code changes 
required at the app level, and it may be better to keep the new projects 
aware of the issue while 3rd parties adapt."

I don't know enough to say whether or not that's the case. Anyway, I think 
a project could evaluate their apps and make a decision to stay with 
REPEATABLE READ or to switch to READ COMMITTED. How do MySQL users feel 
about the two approaches?

[0] https://code.djangoproject.com/ticket/27683
[1] 
https://groups.google.com/d/topic/django-developers/6pWbpV1_6Us/discussion
[2] https://github.com/django/django/pull/7826

-- 
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/1c8af1c8-23dd-4c79-85ce-9486290ae73f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working towards a simpler GCBV implementation?

[James Bennett]

Please read Florian's message. 2.0 is not going to be "we bumped the major
version, now we can pile in lots of breaking changes".

-- 
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/CAL13Cg9afAk2dJp%3DTwSsC2w7DHsE%3DDMpW59cfey16%3DfNab2S9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working towards a simpler GCBV implementation?

[Sayid Munawar]

+1 to use vanilla-views in django 2.0

every time i write some view, i always open https://ccbv.co.uk/ in another 
tabs :D and trying to figure out where should i make my overrides 

On Friday, January 6, 2017 at 5:11:37 PM UTC+7, Alex Scott wrote:
>
> If most everyone agrees that Tom's Vanilla Views are superior than what's 
> currently in core, maybe the path forward is to integrate into 2.0?
>
> On Wednesday, January 4, 2017 at 3:00:03 PM UTC-5, Adam Johnson wrote:
>>
>> Fair enough, there are other community resources for this.
>>
>> The PR adding a pointer in the docs to ccbv.co.uk in 
>> https://github.com/django/django/pull/7785 is a good idea that came from 
>> this thread though.
>>
>> On 4 January 2017 at 13:08, Tim Graham  wrote:
>>
>>> We typically shy away from endorsing third-party libraries in the Django 
>>> docs. I don't think it makes much sense to stay something to the effect of 
>>> "The built-in views are too complex so we recommend using other library 
>>> instead."
>>>
>>>
>>> On Wednesday, January 4, 2017 at 7:30:54 AM UTC-5, Asif Saifuddin wrote:

 Hi,

 I will update the doc pointing vanilla views as simpler alternative 
 implementation.

 Thanks

 On Tuesday, January 3, 2017 at 7:20:24 PM UTC+6, Adam Johnson wrote:
>
> I think this is probably too disruptive a change for Django core, 
> especially after so long with the current GCBV implementations - it would 
> require all users to rewrite their CBV's. Possibly the documentation 
> could 
> recommend django-vanilla-views?
>
> On 3 January 2017 at 13:02, Asif Saifuddin  wrote:
>
>> Hi,
>>
>> I have started work on https://github.com/django/django/pull/7783 
>> for converting django built in generic views to django-vanilla-views.
>>
>> I would like to hear what you think before I proceed for more.
>>
>> Thanks,
>>
>> Asif
>>
>> On Friday, September 16, 2016 at 1:37:36 AM UTC+6, Asif Saifuddin 
>> wrote:
>>>
>>> Hi Tom,
>>>
>>> I am basically +1 to see this change in the django core. The package 
>>> is 3 years old and should be tested enough. If you/other core team 
>>> members 
>>> thinks that now is a good time to include it to core and deprecation of 
>>> older API, then I will be willing to work and send PR for this.
>>>
>>> Looking for others opinions.
>>>
>>> Thanks,
>>>
>>> Asif
>>>
>>> On Thursday, October 3, 2013 at 3:09:58 PM UTC+6, Tom Christie wrote:

 Hi folks,

 I recently released an alternative implementation of Django's 
 existing class based views.  The intention was to mirror the *exact* 
 same 
 set of functionality that we currently provide, but simplify the 
 implementation and API.  It's nothing cleverer or grander than a clean 
 re-write, but the end result is *significantly* less complex.  The 
 class 
 hierarchy is trivial, the API is much smaller, and the flow control is 
 much 
 more obvious.

 I won't go into any more here, as there's plenty of detail in the 
 documentation:

 http://django-vanilla-views.org

 There's also useful context in the related blog post, here:

 http://dabapps.com/blog/fixing-djangos-generic-class-based-views/

 The difficult thing here really is that there's no obvious approach 
 to introducing something like this in a backwards compatible way.

 It might be that we could take an incremental approach using the 
 standard deprecation process, but given the nature of the GCBVs it'd 
 likely 
 be pretty awkward.
 There might be some bits of deprecation process we simply wouldn't 
 be able to deal with in any sensible way, and we'd certainly end up 
 with a 
 seriously gnarly implementation during the deprecation period.

 I'd be interested in getting some opinions from folks on the 
 following:

 * If a simpler GCBV implementation along the lines of 
 django-vanilla-views is something we think we should working towards.
 * What approaches we might be able to take to dealing with 
 backwards compatibility if we did want to do so.

 Thanks for your time.

   Tom

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