Updating default errors in contrib.auth.forms.PasswordResetForm

2012-11-02 Thread Lee Trout
Hi all,

I wasn't sure if it was best to open a ticket or post to the dev group so 
here I am...

I was curious what others thought about changing the default error in the 
PasswordResetForm which currently displays "That e-mail address doesn't 
have an associated user account. Are you sure you've registered?".

I feel like there could be a better default that doesn't expose the fact 
that an email may or may not be in use. (And that probably goes for the 
unusable password error, too.)

Relevant bits:
https://github.com/django/django/blob/stable/1.4.x/django/contrib/auth/forms.py#L191

Lee

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/9EylAZDthMsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Possible deprecation of depth= in select_related

2012-11-02 Thread Marc Tamlyn
Hi all,

The issue #16855 [1] tracks some unexpected behaviour in the chaining of 
`Queryset.select_related`. It's been proving rather complex to get a patch 
for this which works, mainly because of the complexity added by the depth 
argument. It has been proposed (by Luke Plant) that depth be deprecated 
(and +1d by several other users and a core dev). With this in mind, I 
propose that we put the kwarg on the deprecation path adding the warning in 
1.5 (so the bug can eventually be fixed in 1.7). As it changes no 
functionality in this release, I don't see any reason to hold this for 1.6 
(and thereby delay the fix until 1.8).

If anyone has any major objections to the deprecation of depth, you should 
shout now. If there are no objections and people think it's ok to push this 
deprecation in now, then I'll get a patch done on Monday.

Thanks,
Marc


[1] https://code.djangoproject.com/ticket/16855

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/bC-65slJ8gwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Possible deprecation of depth= in select_related

2012-11-02 Thread Jacob Kaplan-Moss
On Fri, Nov 2, 2012 at 9:29 AM, Marc Tamlyn  wrote:
> If anyone has any major objections to the deprecation of depth, you should
> shout now. If there are no objections and people think it's ok to push this
> deprecation in now, then I'll get a patch done on Monday.

No objections here. Depth was a simple protection we added before we
got select_related(*fields); the *fields form is a ton more useful. +1
on deprecating depth.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Github tags

2012-11-02 Thread Florian Apolloner
Hi,

They are (now) all there and signed with the release key: 
https://github.com/django/django/tags -- Please tell us if we missed 
something!

Thx,
Florian

On Friday, November 2, 2012 5:17:25 AM UTC+1, Samus_ wrote:
>
> hi, I think that's great :) in the meantime could you please indicate the 
> commits that will be tagged? thanks!
>
> On Monday, October 29, 2012 1:42:19 PM UTC-2, Jacob Kaplan-Moss wrote:
>>
>> Just so y'all know, this is on the todo list. We want to start doing 
>> signed tags (something cool that we can do now that we use git), so 
>> we've been putting it off until we figure out exactly how to do that 
>> (and, more importantly, who should do the signing.) 
>>
>> Jacob 
>>
>> On Mon, Oct 29, 2012 at 10:30 AM, Yo-Yo Ma  wrote: 
>> > +1 
>> > 
>> > 
>> > On Monday, October 29, 2012 5:18:48 AM UTC-4, Jan Bednařík wrote: 
>> >> 
>> >> There is also related ticket 
>> https://code.djangoproject.com/ticket/19141 
>> >> 
>> >> Jan 
>> >> 
>> >> 
>> >> On Mon, Oct 29, 2012 at 3:36 AM, Matt Austin  
>> >> wrote: 
>> >> > Hi, 
>> >> > 
>> >> > Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5 
>> >> > alpha tagged on the github repository? The tagging seems to have 
>> >> > fallen behind with these releases. 
>> >> > 
>> >> > Thanks, 
>> >> > 
>> >> > -- 
>> >> > Matt 
>> >> > 
>> >> > -- 
>> >> > You received this message because you are subscribed to the Google 
>> >> > Groups "Django developers" group. 
>> >> > To post to this group, send email to django-d...@googlegroups.com. 
>> >> > To unsubscribe from this group, send email to 
>> >> > django-develop...@googlegroups.com. 
>> >> > For more options, visit this group at 
>> >> > http://groups.google.com/group/django-developers?hl=en. 
>> >> > 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "Django developers" group. 
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msg/django-developers/-/qWKMQb_tsmAJ. 
>> > 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > To unsubscribe from this group, send email to 
>> > django-develop...@googlegroups.com. 
>> > For more options, visit this group at 
>> > http://groups.google.com/group/django-developers?hl=en. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/0QHFv08ao8kJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



#16779 - a tutorial for first time Django contributors

2012-11-02 Thread Tim Graham
Taavi Taijala has written a tutorial for new contributors that I've given 
an initial review.  I'm hoping we can get a few more sets of eyes on it. 
 Might be useful to pass it on to any newbies you know and have them try it 
out as well.  Thanks!

https://code.djangoproject.com/ticket/16779

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/-_1dshZ5wDIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Updating default errors in contrib.auth.forms.PasswordResetForm

2012-11-02 Thread Russell Keith-Magee
Hi Lee,

What you propose certainly sounds reasonable -- anything that reduces the
exposure of valid accounts to an external source is a good thing, IMHO.

Did you have an alternative wording to suggest? If you do, please open a
ticket.

Yours,
Russ Magee %-)

On Fri, Nov 2, 2012 at 9:42 PM, Lee Trout  wrote:

> Hi all,
>
> I wasn't sure if it was best to open a ticket or post to the dev group so
> here I am...
>
> I was curious what others thought about changing the default error in the
> PasswordResetForm which currently displays "That e-mail address doesn't
> have an associated user account. Are you sure you've registered?".
>
> I feel like there could be a better default that doesn't expose the fact
> that an email may or may not be in use. (And that probably goes for the
> unusable password error, too.)
>
> Relevant bits:
>
> https://github.com/django/django/blob/stable/1.4.x/django/contrib/auth/forms.py#L191
>
> Lee
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/9EylAZDthMsJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Possible deprecation of depth= in select_related

2012-11-02 Thread Russell Keith-Magee
On Fri, Nov 2, 2012 at 10:33 PM, Jacob Kaplan-Moss wrote:

> On Fri, Nov 2, 2012 at 9:29 AM, Marc Tamlyn  wrote:
> > If anyone has any major objections to the deprecation of depth, you
> should
> > shout now. If there are no objections and people think it's ok to push
> this
> > deprecation in now, then I'll get a patch done on Monday.
>
> No objections here. Depth was a simple protection we added before we
> got select_related(*fields); the *fields form is a ton more useful. +1
> on deprecating depth.
>
>
Sounds good to me too. +1.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: Updating default errors in contrib.auth.forms.PasswordResetForm

2012-11-02 Thread Donald Stufft
The canonical way of handling this so as not to leak information like that is 
to do exactly the same thing UX wise for success and failures, and just update 
the message to state that if an email address by that account has been 
registered they will get an email soon. 


On Friday, November 2, 2012 at 9:18 PM, Russell Keith-Magee wrote:

> Hi Lee,
> 
> What you propose certainly sounds reasonable -- anything that reduces the 
> exposure of valid accounts to an external source is a good thing, IMHO. 
> 
> Did you have an alternative wording to suggest? If you do, please open a 
> ticket. 
> 
> Yours,
> Russ Magee %-)
> 
> On Fri, Nov 2, 2012 at 9:42 PM, Lee Trout  (mailto:leetr...@gmail.com)> wrote:
> > Hi all,
> > 
> > I wasn't sure if it was best to open a ticket or post to the dev group so 
> > here I am... 
> > 
> > I was curious what others thought about changing the default error in the 
> > PasswordResetForm which currently displays "That e-mail address doesn't 
> > have an associated user account. Are you sure you've registered?". 
> > 
> > I feel like there could be a better default that doesn't expose the fact 
> > that an email may or may not be in use. (And that probably goes for the 
> > unusable password error, too.)
> > 
> > Relevant bits:
> > https://github.com/django/django/blob/stable/1.4.x/django/contrib/auth/forms.py#L191
> > 
> > Lee 
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/django-developers/-/9EylAZDthMsJ.
> > To post to this group, send email to django-developers@googlegroups.com 
> > (mailto:django-developers@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com 
> > (mailto:django-developers%2bunsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

2012-11-02 Thread Christian Jensen
I was just writing some code against 1.5 and thought I might use the new 
.save(update_fields=['xyz']) then I realized I was using PostgreSQL - which 
is an MVCC... which re-writes the entire row as far as I know even when one 
column is being updated.

I popped into the release notes and it does in fact indicate that it is 
useful for high concurrency scenarios.

I thought it would be nice to note in the docs somewhere that it is really 
not useful for database of this type unless you are using a healthy amount 
of the update_fields elsewhere.

I might be wrong on all of this.

I have never made a documentation change nor have any idea what the process 
would be so if someone chooses to make this note, please do!

Thanks everyone!
Christian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/LIGJJ2qwBZgJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

2012-11-02 Thread Donald Stufft
The major help is preventing clobbering a value for concurrency.

Prior to this when you loaded an object from SQL into a django model, it would 
fetch all the values
as they were at that time, and store them in the model instance. Then when you 
saved it it would
write all those values back out to the database, even if someone else had 
changed them and
you didn't.

Now if you fetch a particular instance, and make a change, you can save only 
that value, and you
won't clobber other peoples saves if they made a change to an unrelated field 
on that row.


On Friday, November 2, 2012 at 9:42 PM, Christian Jensen wrote:

> I was just writing some code against 1.5 and thought I might use the new 
> .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which 
> is an MVCC... which re-writes the entire row as far as I know even when one 
> column is being updated.
> 
> I popped into the release notes and it does in fact indicate that it is 
> useful for high concurrency scenarios.
> 
> I thought it would be nice to note in the docs somewhere that it is really 
> not useful for database of this type unless you are using a healthy amount of 
> the update_fields elsewhere.
> 
> I might be wrong on all of this.
> 
> I have never made a documentation change nor have any idea what the process 
> would be so if someone chooses to make this note, please do!
> 
> Thanks everyone!
> Christian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/LIGJJ2qwBZgJ.
> To post to this group, send email to django-developers@googlegroups.com 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: 1.5, update_fields and PostgreSQL (or other MVCC style database) - request for documentation note

2012-11-02 Thread Christian Jensen
Exactly... I guess I was just asking for someone to say 'Don't use this if
you think it will make the update any faster on Postgres' in the docs... in
addition to what you just said :)

On Fri, Nov 2, 2012 at 7:45 PM, Donald Stufft wrote:

>  The major help is preventing clobbering a value for concurrency.
>
> Prior to this when you loaded an object from SQL into a django model, it
> would fetch all the values
> as they were at that time, and store them in the model instance. Then when
> you saved it it would
> write all those values back out to the database, even if someone else had
> changed them and
> you didn't.
>
> Now if you fetch a particular instance, and make a change, you can save
> only that value, and you
> won't clobber other peoples saves if they made a change to an unrelated
> field on that row.
>
> On Friday, November 2, 2012 at 9:42 PM, Christian Jensen wrote:
>
> I was just writing some code against 1.5 and thought I might use the new
> .save(update_fields=['xyz']) then I realized I was using PostgreSQL - which
> is an MVCC... which re-writes the entire row as far as I know even when one
> column is being updated.
>
> I popped into the release notes and it does in fact indicate that it is
> useful for high concurrency scenarios.
>
> I thought it would be nice to note in the docs somewhere that it is really
> not useful for database of this type unless you are using a healthy amount
> of the update_fields elsewhere.
>
> I might be wrong on all of this.
>
> I have never made a documentation change nor have any idea what the
> process would be so if someone chooses to make this note, please do!
>
> Thanks everyone!
> Christian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/LIGJJ2qwBZgJ.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>



-- 

*Christian Jensen*
724 Ioco Rd
Port Moody, BC V3H 2W8
+1 (778) 996-4283
christ...@jensenbox.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.