On Fri, Oct 8, 2010 at 11:28 AM, Laurent Luce wrote:
> I noticed that create_user() is currently setting password to unusable
> if it is None or empty. However, set_password() is accepting an empty
> password. I decided to follow the first rule in the patch I submitted
> but I am kind of confused
I noticed that create_user() is currently setting password to unusable
if it is None or empty. However, set_password() is accepting an empty
password. I decided to follow the first rule in the patch I submitted
but I am kind of confused now. Can someone indicate what we should
accept as a password?
Bringing this back for more design decision discussion. I've started a
(very basic) wiki page with a brief summation of the situation here:
http://code.djangoproject.com/wiki/PylibmcSupport
Of note from that wiki page are three main issues I raised with
various django developers while at Django Co
Hi,
I started working on a somehow related ticket #14390. Adrian suggested
to create a utils module, so I wanted to put there all useful
password-related functions: check_password(), make_password(),
is_password_usable() and the UNUSABLE_PASSWORD constant. So I'm
interested in API that this functi
I'd be interested in helping out as well In any way I can. I'm a technical
writer/editor by day so if there is a need for someone to oversee or assist
with documentation I'd be delighted. Of course I'm willing to help out on
anything.
Best,
Steve
Sent from my iPhone
On Oct 7, 2010, at 4:15 P
Great idea!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more opt
Hello,
Regarding the issue about password is None in check_password (http://
code.djangoproject.com/ticket/14354). I attached a patch with the
following changes:
- in set_password(), check for raw_password and if None or empty, call
set_unusable_password(), otherwise same as before
- in has_usab
I'd definitely be up for helping out with this.
- Marco
On Oct 7, 3:36 pm, Shawn Davis wrote:
> I can participate if it's "several someones", but I'm afraid my schedule is
> too full to do it solo.
>
> thanks,
> Shawn
>
> On Oct 7, 2010, at 5:30 PM, Jacob Kaplan-Moss wrote:
>
>
>
> > Hi folks -
I can participate if it's "several someones", but I'm afraid my schedule is too
full to do it solo.
thanks,
Shawn
On Oct 7, 2010, at 5:30 PM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> Google's open source team is putting together a new program, called
> "Google Code-in". It's a program to get
On Thu, Oct 7, 2010 at 3:30 PM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> Google's open source team is putting together a new program, called
> "Google Code-in". It's a program to get 13-18 years old students
> involved in open source by giving them sets of small, distinct tasks
> to work on. The
Hi folks --
Google's open source team is putting together a new program, called
"Google Code-in". It's a program to get 13-18 years old students
involved in open source by giving them sets of small, distinct tasks
to work on. They did a similar program last year, called GHOP; Django
didn't partici
> Sorry, I should have been more clear.
>
> What I'm trying to do is solicit suggestions from django developers as
> to how I *can* move ticket #1946 forward. I can find a way to work
> around it in my own project, but it would be ideal to solve it on the
> Django side, for everybody.
>
> I mention
On Thu, Oct 7, 2010 at 9:42 AM, Jacob Kaplan-Moss wrote:
> You know, I really don't think this is a big enough deal to bother
> being completely picky about the deprecation policy here. It's a silly
> setting that should have been removed pre-open-source when we did the
> whole Django/Ellington sp
On Wed, Oct 6, 2010 at 10:30 PM, Russell Keith-Magee
wrote:
> Strictly, it needs to be put on a deprecation path [...]
You know, I really don't think this is a big enough deal to bother
being completely picky about the deprecation policy here. It's a silly
setting that should have been removed pr
On Thu, Oct 7, 2010 at 7:33 PM, Luke Plant wrote:
> On Thu, 2010-10-07 at 18:50 +0800, Russell Keith-Magee wrote:
>
>> The set of people that will be affected here are are all opt-in --
>> they've had to set COMMENTS_ALLOW_PROFANITIES=True -- so I would have
>> assumed that some subset will be hap
On Thu, 2010-10-07 at 18:50 +0800, Russell Keith-Magee wrote:
> The set of people that will be affected here are are all opt-in --
> they've had to set COMMENTS_ALLOW_PROFANITIES=True -- so I would have
> assumed that some subset will be happy with the default
> PROFANITIES_LIST as currently defin
On Thu, Oct 7, 2010 at 6:15 PM, Luke Plant wrote:
> On Thu, 2010-10-07 at 11:30 +0800, Russell Keith-Magee wrote:
>
>> Strictly, it needs to be put on a deprecation path, because it *is*
>> documented, in ref/settings.txt. So the earliest we can truly remove
>> it is in 1.5, after a PendingDepreca
On Thursday 07 October 2010 07:31:49 Russell Keith-Magee wrote:
>
> It certainly sounds to me like a legitimate bug (or group of bugs).
>
It is now bug #14415.
Thanks,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
On Thu, 2010-10-07 at 11:30 +0800, Russell Keith-Magee wrote:
> Strictly, it needs to be put on a deprecation path, because it *is*
> documented, in ref/settings.txt. So the earliest we can truly remove
> it is in 1.5, after a PendingDeprecationWarning in 1.3 and a full
> Warning in 1.4.
>
> Alon
There are at least three open tickets related to OneToOneFields
(#10227, #14043, #14368) that, even if deemed invalid, hint at lack of
adequate documentation. After reading the docs on OneToOneField, I
don't think one can easily answer the following questions:
- It is mentioned that multi-table in
20 matches
Mail list logo
