Re: A policy on calling super()

2013-09-30 Thread Aymeric Augustin
I read the original request as a matter of principle and not something born 
from an actual need.

View is intended to be the rightmost class in an inheritance scheme. I haven't 
seen a sane use case for injecting it as a mixin.

This change is more likely to allow beginners to shoot themselves into the foot 
with an ill-conceived inheritance scheme than the status quo is to prevent 
advanced and interesting uses.

In general I'm not eager to make constructs without practical value possible. 
Read this as a -0.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/367C1BCA-2446-4C59-9FA4-CCDFBB6476B8%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.


Re: filtering a QuerySet after a slice

2013-09-30 Thread Rimvydas Naktinis
I completely agree with Gary's argumentation here. And I would love to see 
.limit() introduced (or array slicing adapted).

I ran into a situation where I have access into intermediate queryset() 
construction, where I normally do add .filter() statements, but now I had 
to limit a number of queries returned and it caused an exception, because 
some other code further down the stack was modifying.

The actual query construction should be the final step, and in that case it 
doesn't matter when and how many times an equivalent of .limit() (or for 
that matter slicing) was called on the queryset. Just use the final one.

On Wednesday, December 5, 2007 5:14:55 AM UTC, Gary Wilson wrote:
>
> Luke Plant wrote:
> > On Tuesday 04 December 2007 07:25:31 Gary Wilson wrote:
> > 
> >> Sort of my point.  Since filter() and [:] both return QuerySets why
> >> should they be any different:
> >>
> >> UTPerson.objects.all().filter(name__startswith='a')[:10]
> > 
> > 1) This, logically, should return the first ten people whose 'name' 
> > starts with 'a'.
> > 
> >> UTPerson.objects.all()[:10].filter(name__startswith='a')
> > 
> > 2) This should return the people whose 'name' starts with 'a' from the 
> > first 10 rows in the table
> > 
> > This is almost certainly what most people would expect (I guess we could 
> > argue about that...)  But there is no way to specify it in SQL without 
> > doing subselects -- you will end up doing 1) instead.  
>
> Does that mean that most people also expect:
>
>
> UTPerson.objects.filter(first_name__startswith='a').filter(last_name__startswith='b')
>
> to return the people whose last name starts with 'b' from the people whose
> first name starts with 'a'?  Maybe, but filter doesn't work that way just 
> like
> slicing wouldn't work that way.
>
> I should be able to keep piling things onto the QuerySet.  You can do it 
> with
> all the other QuerySet methods that return QuerySets.  Why not with the
> slicing syntax (which returns a QuerySet object)?
>
> I am just trying to spark some discussion on the matter.  Personally, I
> wouldn't mind if slices were changed to always return lists (like the do
> currently if you use a step).  And then we and in a limit() method for 
> people
> who want QuerySets returned so that they can be built up and lazily 
> evaluated.
>
> I see:
>
> UTPerson.objects.all().limit(10).filter(...).limit(10)
>
> acting like order_by() in that the second limit would override the first.
>
> > Remember that there are other methods that do not or cannot commute e.g. 
> > trying to do order_by() after slicing -- it would change the objects 
> > that are returned.  Just because some methods do happen to commute 
> > (filtering) doesn't mean that others should.
>
> Well, with order_by() you can do:
>
>
> UTPerson.objects.all().order_by('first_name').filter(...).order_by('last_name')
>
> In this case, the second order_by() overrides the first.
>
> Gary
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/be64f70b-4443-4c76-9ff5-db3f35fdef14%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: filtering a QuerySet after a slice

2013-09-30 Thread Michael Manfre
Array slicing doesn't always return a QuerySet and shouldn't be adapted to
this proposed behavior. Directly exposing Query.set_limits() on the
QuerySet would most likely have confusing behavior to at least some group
of people.

Given the current behavior of Query.set_limits(), what should be the slice
start/stop for the below?

UTPerson.objects.all().set_limits(low=1,
high=10).filter(...).set_limits(low=1, high=10)

If you guessed, low=1 and high=10, you'd be wrong. Subsequent calls to
set_limits() "are applied relative to the existing constraints." That
behavior can be changed by having the QuerySet.set_limits() call
Query.clear_limits() before Query.set_limits(), but that would probably be
confusing to those that are familiar with how Query.set_limits() behaves.

If you want to be able to further filter and reapply/change the limits, you
can do that already. You can't do it as chained QuerySet calls, but the
only time this would make sense in code is when a QuerySet was passed with
a potentially unknown can_filter state, so you'd need to reset it before
using it.

if not qs.query.can_filter():
qs.query.clear_limits()
qs.filter(...)[:10]

Regards,
Michael Manfre



On Mon, Sep 30, 2013 at 9:41 AM, Rimvydas Naktinis wrote:

> I completely agree with Gary's argumentation here. And I would love to see
> .limit() introduced (or array slicing adapted).
>
> I ran into a situation where I have access into intermediate queryset()
> construction, where I normally do add .filter() statements, but now I had
> to limit a number of queries returned and it caused an exception, because
> some other code further down the stack was modifying.
>
> The actual query construction should be the final step, and in that case
> it doesn't matter when and how many times an equivalent of .limit() (or for
> that matter slicing) was called on the queryset. Just use the final one.
>
> On Wednesday, December 5, 2007 5:14:55 AM UTC, Gary Wilson wrote:
>>
>> Luke Plant wrote:
>> > On Tuesday 04 December 2007 07:25:31 Gary Wilson wrote:
>> >
>> >> Sort of my point.  Since filter() and [:] both return QuerySets why
>> >> should they be any different:
>> >>
>> >> UTPerson.objects.all().filter(**name__startswith='a')[:10]
>> >
>> > 1) This, logically, should return the first ten people whose 'name'
>> > starts with 'a'.
>> >
>> >> UTPerson.objects.all()[:10].**filter(name__startswith='a')
>> >
>> > 2) This should return the people whose 'name' starts with 'a' from the
>> > first 10 rows in the table
>> >
>> > This is almost certainly what most people would expect (I guess we
>> could
>> > argue about that...)  But there is no way to specify it in SQL without
>> > doing subselects -- you will end up doing 1) instead.
>>
>> Does that mean that most people also expect:
>>
>> UTPerson.objects.filter(first_**name__startswith='a').filter(**
>> last_name__startswith='b')
>>
>> to return the people whose last name starts with 'b' from the people whose
>> first name starts with 'a'?  Maybe, but filter doesn't work that way just
>> like
>> slicing wouldn't work that way.
>>
>> I should be able to keep piling things onto the QuerySet.  You can do it
>> with
>> all the other QuerySet methods that return QuerySets.  Why not with the
>> slicing syntax (which returns a QuerySet object)?
>>
>> I am just trying to spark some discussion on the matter.  Personally, I
>> wouldn't mind if slices were changed to always return lists (like the do
>> currently if you use a step).  And then we and in a limit() method for
>> people
>> who want QuerySets returned so that they can be built up and lazily
>> evaluated.
>>
>> I see:
>>
>> UTPerson.objects.all().limit(**10).filter(...).limit(10)
>>
>> acting like order_by() in that the second limit would override the first.
>>
>> > Remember that there are other methods that do not or cannot commute
>> e.g.
>> > trying to do order_by() after slicing -- it would change the objects
>> > that are returned.  Just because some methods do happen to commute
>> > (filtering) doesn't mean that others should.
>>
>> Well, with order_by() you can do:
>>
>> UTPerson.objects.all().order_**by('first_name').filter(...).**
>> order_by('last_name')
>>
>> In this case, the second order_by() overrides the first.
>>
>> Gary
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/be64f70b-4443-4c76-9ff5-db3f35fdef14%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.

Re: AbstractUser to get more abstract

2013-09-30 Thread Russell Keith-Magee
On Wed, Sep 25, 2013 at 8:04 AM, Luke Sneeringer wrote:

> Good evening, Russell, et. al.,
> I had some time this afternoon. :-) Since there are already a couple of
> reference implementations for how to do this with an e-mail app, I decided
> to take a crack at an implementation that would include an EmailUser within
> the base auth app. I understand we've far from decided on a method, and I
> still stand by my promise to do whatever Russell decides, but I figured
> code to look at would be a good thing, and that it would give me a better
> idea of the task.
>
> Here's the branch:
> https://github.com/lukesneeringer/django/tree/ticket-20824-noemailapp
>
> I have a few observations and self-criticisms:
>
>
>- The big advantage, as I see it, to this approach over a separate-app
>approach is that it *drastically* reduces code duplication. Forms, the
>admin, etc., all use the same classes they did before, just those classes
>are now a bit more aware of what the USERNAME_FIELD and REQUIRED_FIELDS
>are. This is really the reason I believe this to be the correct approach. A
>separate app would have to be maintained, well, separately. :-)
>
> I completely fail to see why this is the case. You seem to be implying
that by putting the EmailUser model in a separate app, this means we need
to duplicate code. Why can't you:

* Put a base class in contrib.auth and put a subclass in contrib.email_auth
* Put the model and admin registration in contrib.email_auth and point at
contrib.auth.forms.

If there truly is common base functionality, then *put it in a base class*,
and use that base class.

DRY doesn't mean you don't *EVER* duplicate code. It means that you only
ever express an *idea* once. If you have two ideas, and they're actually
different, the fact that they've got largely similar implementations
doesn't mean you tie yourself in knots trying to avoid typing the same
characters twice. At the end of the day, practicality beats purity.
"Duplicating" a handful of lines of code at the cost of a simple,
predictable implementation is a hands-down win in my book.

This is especially true when you consider that we're dealing with user
authentication here, which has huge implications for the security of Django
as a platform. Authentication is literally the front line of framework
security, because it's how you get authenticated to do stuff in the first
place. Complex implementations mean edge cases accidentally slip through;
simple implementations don't allow those problems.

>
>- I have a few criticisms of my approach, now that I've had a chance
>to see it in action:
>   - The create_user and create_superuser methods on UserManager were
>   a bit of a land mine. The current (1.6) implementation takes username,
>   email, and password as positional arguments, and making this into an
>   all-kwarg approach would break back-compat. I landed on a solution, but 
> I'm
>   not sure it's the right one.
>
>
>- In order to maintain the form error message but not have the form
>   itself be opinionated about the presence of "username", I removed the
>   explicit validator on the form, simply letting ModelForm outsource it to
>   the Model. This provides the same error message for both invalid and
>   duplicate usernames / e-mail addresses (as appropriate). I think this
>   actually might be a *good* thing (again, code duplication is reduced), 
> but
>   I don't really know if there's some reason why it was constructed the 
> way
>   it was before.
>   - There's a special message for duplicate usernames ("A user with
>   that username already exists."), and it's not a trivial thing to just 
> make
>   an e-mail address correlate because of internationalization. I reverted 
> to
>   the previous message, which was translated ("Please correct the 
> duplicate
>   data for email, which must be unique."), because I really don't know 
> what
>   the appropriate procedure is here. (This would be an issue with a
>   separate-app approach too, but it's on my list of "things I didn't 
> know".)
>   - In starting to write tests (not committed), I hit an interesting
>   situation where overwriting AUTH_USER_MODEL using override_settings may 
> not
>   be sufficient, which is an issue I would need to figure out. I expect 
> this
>   would not be a problem in an email_auth app, since the model wouldn't be
>   loaded until after the override.
>
> … and all of these are exactly the problems that I predicted -- that
you'll end up with complex (and potentially backwards incompatible)
internals, or weird logic switching between models, or problems with tests
binding the User model to a global context.


> Russell, I definitely understand that you're still not sold on this
> method. I think that at this point, I've made my case, and if you're still
> not sold, I'm ready to coalesce the email_auth app implementations (two

Re: AbstractUser to get more abstract

2013-09-30 Thread Russell Keith-Magee
Hi Rocky,

On Thu, Sep 26, 2013 at 4:17 PM, Rocky Meza  wrote:

>
> Hi,
>
> I'm another one of the authtools devs.
>
> On Tuesday, September 24, 2013 6:04:17 PM UTC-6, Luke Sneeringer wrote:
>>
>> Good evening, Russell, et. al.,
>> This is a problem that we ran into with authtools, what we ended up doing
>> was just running the tests 3 times[1].  I don't think this is a realistic
>> approach within Django core though.  One of the main problems with this is
>> that you use get_user_model at the root level of the forms module, so the
>> Form will be declared against only one model--I don't know what you can do
>> though.  Having email_auth as a separate app would probably clear up this
>> problem for the tests, but if that happens then we would just have to
>> concrete specific sets of forms, instead of more generic Forms, which was
>> the whole idea.  The only situation where you should be switching settings
>> around is in tests, so I do think it is a little unfair to compromise the
>> generic nature of the forms just to appease the tests.
>>
>
>> Not only is it a realistic approach -- it is (within limits) what the
current Django core already does. In order to validate that Django's
pluggable user infrastructure actually does what it is supposed to do
(i.e., let people with different user models use default auth views etc),
Django's auth app ships 7 test User models, and large chunks of the test
suite are run for each of those models. It's not a case of running the
*entire* auth test suite repeatedly; it's matter of finding the parts of
logic that are User model dependent, and running *those* tests repeatedly.

So - it's entirely possible and realistic - as long as you don't bind one
specific User model into a global context. Which is one of the reasons why
having a separate app helps :-)

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAJxq8487vETjcxHRq%2BwnjawY5t726bJ6HawMXB3VAy11W%2BxotQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


Remove contrib redirect's dependency on sites

2013-09-30 Thread Simon Litchfield
Contrib redirects is still a handy little app, but it's dependency on 
contrib.sites is often unnecessary and a little annoying.

Would anyone else be keen to see the dependency removed, gracefully? If so 
I'll spin up the code.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/6bd7adfc-13e6-46f7-aec3-d1b84243e2e9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.