Re: #3400 -- ModelAdmin.list_filter improvements

[Russell Keith-Magee]

My apologies, Simon. This has been on my list of things to look at,
but people keep putting more things on top of that list :-)

I've had a cursory look at the patch, and it looks good. I'll need to
take a much closer look before I commit anything, but it certainly
looks to be on the right path. This doesn't rate as a major feature,
so I probably won't be able to give it any attention before Oct 18
when 1.3 alpha ships.

One quick question, though: what's the overlap with #5833 (another
often requested, never committed feature)? It seems to me like the two
have a lot in common -- possibly that #3400 could be implemented in
terms of #5833. At the very least, the two patches are touching
similar code, so it would be good to make sure they are consistent.

Yours,
Russ Magee %-)

On Sat, Oct 9, 2010 at 7:06 AM, Simon Meers  wrote:
> Anyone? I know it is a relatively complex patch to review, but it would be a
> shame to see such a frequently requested feature/fix miss the 1.3 boat.
>
> On 29 August 2010 08:06, Simon Meers  wrote:
>>
>> A gentle reminder to anyone who would like to review the recent patch
>> uploaded for #3400 [1].
>>
>> I have come across quite a number of people who consider list_filter's
>> current inability to span relationships (e.g. as search_fields can) to be
>> one of the more obvious/annoying of Django's limitations and would love to
>> see it implemented.
>>
>> [1] http://code.djangoproject.com/ticket/3400
>
> --
> 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 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-develop...@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: Congratulations!

[Gabriel Hurley]

If you glance at the revision log for the committers page in the docs,
there are actually a couple more ;-)

http://code.djangoproject.com/log/django/trunk/docs/internals/committers.txt

On Oct 8, 6:15 pm, Łukasz Rekucki  wrote:
> I just noticed we have 2 new Core Developers: Alex Gaynor and Andrew
> Godwin and a new Admin Specialist Simon Meers.
>
> Just wanted to say: Congratulations guys and keep up the good work! :)
>
> --
> Łukasz Rekucki

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Congratulations!

[sj l]

Great!

2010/10/9 Łukasz Rekucki 

> I just noticed we have 2 new Core Developers: Alex Gaynor and Andrew
> Godwin and a new Admin Specialist Simon Meers.
>
> Just wanted to say: Congratulations guys and keep up the good work! :)
>
> --
> Łukasz Rekucki
>
> --
> 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 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-develop...@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.

Congratulations!

[Łukasz Rekucki]

I just noticed we have 2 new Core Developers: Alex Gaynor and Andrew
Godwin and a new Admin Specialist Simon Meers.

Just wanted to say: Congratulations guys and keep up the good work! :)

-- 
Łukasz Rekucki

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: password is None in check_password

[Laurent Luce]

I just want to summarize the password handling changes before and
after this patch.

before:
- create_user() with empty password or None -> password set to '!'
unusable
- set_password() accepts everything
- has_usable_password() returning False for password equal to '!'

after:
- create_user() with password None -> password set to '!' unusable
- set_password() with None -> password set to '!' unusable
- has_usable_password() returning False for password equal to '!' or
None

Laurent

On Oct 8, 4:47 pm, Laurent Luce  wrote:
> Thanks for your feedback. I attached a new patch with the following
> changes:
>
> * allow empty string in set_password()
> * has_usable_password() returns false if password is '!' or None
> * add unit test set_password(None)
> * add verbosity option to createsuperuser command + unit test
> * output msg to stdout in createsuperuser command + update unit tests
>
> Let me know if the patch still needs improvement.
>
> Laurent Luce
>
> On Oct 7, 11:17 pm, Russell Keith-Magee 
> wrote:
>
> > 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 now. Can someone indicate what we should
> > > accept as a password?
>
> > An empty string isn't a *good* password, but then neither is a single
> > character or a dictionary word, and we don't reject those. Policy
> > decisions like this aren't the domain of a web framework.
>
> > I'm sure there are also people using an empty password as the "I don't
> > actually want security" password. Plus, there's a history in the free
> > software community of using empty passwords as a protest [1] :-)
>
> > We can use None to mark an unusable password. Absent of a good
> > technical reason, I don't see why we should reject empty string.
>
> > As for the remainder of the patch on #14354 -- on the whole, it looks
> > good. I've put some review comments on the ticket.
>
> > [1]http://en.wikipedia.org/wiki/Richard_Stallman#Early_years
>
> > Yours,
> > Russ Magee %-)

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #3400 -- ModelAdmin.list_filter improvements

[Simon Meers]

Anyone? I know it is a relatively complex patch to review, but it would be a
shame to see such a frequently requested feature/fix miss the 1.3 boat.

On 29 August 2010 08:06, Simon Meers  wrote:

> A gentle reminder to anyone who would like to review the recent patch
> uploaded for #3400 [1].
>
> I have come across quite a number of people who consider list_filter's
> current inability to span relationships (e.g. as search_fields can) to be
> one of the more obvious/annoying of Django's limitations and would love to
> see it implemented.
>
> [1] http://code.djangoproject.com/ticket/3400
>

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Migrating doctests to unittests

[Filip Gruszczyński]

Thanks :-)

2010/10/8 Alex Gaynor :
> Yes, and yes. :)
>
> Alex
>
> 2010/10/8 Filip Gruszczyński :
>> I am not sure, but I think I have seen it mentioned somewhere, so I
>> would like to ask: are tests django being migrated from doctests to
>> unit tests and is it desirable to provide patches with such migration?
>>
>> --
>> Filip Gruszczyński
>>
>> --
>> 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 options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
> 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 options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
Filip Gruszczyński

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Migrating doctests to unittests

[Alex Gaynor]

Yes, and yes. :)

Alex

2010/10/8 Filip Gruszczyński :
> I am not sure, but I think I have seen it mentioned somewhere, so I
> would like to ask: are tests django being migrated from doctests to
> unit tests and is it desirable to provide patches with such migration?
>
> --
> Filip Gruszczyński
>
> --
> 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 options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>



-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Migrating doctests to unittests

[Filip Gruszczyński]

I am not sure, but I think I have seen it mentioned somewhere, so I
would like to ask: are tests django being migrated from doctests to
unit tests and is it desirable to provide patches with such migration?

-- 
Filip Gruszczyński

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Field localize useless

[Michel Thadeu Sabchuk]

Hi guys, how are you?

I had problems with DecimalField and localize input/output. I found
the bug and I'm working on it:

http://code.djangoproject.com/ticket/14101

While I digging to find the bug, I see that the DecimalField (and even
the Field class) uses a "localize" attribute. I think this localize
attribute is useless and I not alone:

http://groups.google.com/group/django-developers/browse_thread/thread/68d2f628bca73e4d/5b576a1f9f4a32ed?lnk=gst=localize#5b576a1f9f4a32ed

The localize attribute controls the usage of the formats methods like
sanitize_separators or number_format. Reather than control it with a
keyword argument for the field class, we should use the USE_L10N
setting. But the formats methods already check it, so we can just call
the methods on the field class, without bother is USE_L10N is on or
off.

What do you think? Can I create a ticket for it?

Best regards!


-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

#12991 unittest2 support -- Final call for comment

[Russell Keith-Magee]

Hi all,

This is a final call for comment on #12991, the introduction of
unittest2. Barring objection, my intention is to commit this on
Monday.

I've now had confirmation that the suite passes under GIS, and a
couple more reports of successful test passes under different Python
versions and databases.

I've just uploaded an RC2 patch, with a couple of minor updates
following a review from Alex Gaynor (Thanks Alex!):

 * The markup tests have been split to ensure that the 'library X' not
installed case is tested in the same way it is currently

 * The Vendor name has been made a class variable, rather than an
instance variable on the database backends

 * A couple minor exception handling and docstring clarifications have
been made.

Speak now, etc etc.

Yours,
Russ Magee %-)

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pylibmc Support: Part 2

[Jeremy Dunck]

On Fri, Oct 8, 2010 at 2:36 AM, Russell Keith-Magee
 wrote:
...
> Also, are there any API-level discrepancies remaining that need to be
> considered? The earlier django-dev thread suggests that there are some
> problems with get_multi(), but it also says that they've been fixed.
> Is this the case?

FWIW, Eric's django-newcache supports pylibmc and deals with the
safety issue by making the cache client instance a thread local.

http://github.com/ericflo/django-newcache/blob/c661235705b72d70d1765c7dc197e798e0424eeb/newcache.py#L61

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: AutoFields, legacy databases and non-standard sequence names.

[akaariai]

On 8 loka, 10:41, Hanne Moa  wrote:

> You can't necessarily do this with a legacy database, as other systems
> also using that database expect the existing names.

alter sequence owned by does not change the sequnce name, just what
pg_get_serial_sequence will return for given table, column
combination. But as said, if there are multiple tables using the same
sequence, then alter sequence owned by does not work. In these cases
manually settable sequence names for models is likely the best
solution.

>
> I need to use my own backend because of posgresql's own
> table-inheritance. Most tables in the db inherit from the same table
> and inherits its primary key and the sequence for that primary key.
> Then there are a few tables that inherits from a table that inherits
> from the grandfather table that defines the primary key and its
> sequence. So, I need to recursively discover the oldest ancestor of
> each table and use the sequence of that ancestor.
>
> HM

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: OneToOneField clarifications

[Russell Keith-Magee]

On Thu, Oct 7, 2010 at 5:30 PM, George Sakkis  wrote:
> 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 inheritance in implemented with an
> implicit O2O relation from the child to the parent model, but O2O is
> also useful for cases where neither model "extends" (in the OO sense)
> the other. What are the implications of model A linking to model B
> versus the inverse ?
> - Does A.save() propagate to the linked B instance (if any) or vice
> versa ?
> - Does A.delete() propagate to the linked B instance (if any) or vice
> versa ?
> - Is "A.link_to_B = B" equivalent to "B.link_to_A = A" ?
> - Is "A.link_to_B = None" or "B.link_to_A = None" valid ?
> - Are the assignments above done exclusively in memory or they may hit
> the database for reading and/or writing ?
> - How does null=True affect the answers to all the above ?
>
> Having clear answers to these would be a good first step to moving on
> with the mentioned tickets and perhaps augmenting the docs.

The problem we have here is that O2O fields are the worst possible
case for the leaky abstraction that forms the basis of the ORM.
ForeignKeys have the same problems, but they're not quite as acute
because they at least *appear* asymmetrical.

*In theory* there shouldn't be a difference between which side of the
fence you operate upon.

However, in practice, there is. One of the two models has to store the
column that represents the relation. If A contains the field
definition, you need to save the instance of A in order to make a
relation change persist.

This means that the pure object abstraction gets leaky, and you have
to care a little bit about which model holds the physical
manifestation of your relation. And pretty much all the questions you
ask related to exactly how leaky the abstraction is (or should be).

So - the overarching behavior should be that it the ORM looks and
feels like you're manipulating a bunch of objects. However, there are
practical limitations to that pure vision, and places where the
abstraction leaks, and the solution we've implemented is mindful of
that fact.

Looking at the specific bugs in question:



#10227 is a bit of a weird one (which is why it's DDN). I can
certainly see the argument for why the reverse case should return None
rather than an exception. If you consider a O2O field to be a
ForeignKey with unique=True (which is essentially how they're
implemented), you don't get an exception when there is no objects in
your object_set.all(); you get an empty query set. I think there's
grounds to say that "None" should be the O2O interpretation of an
empty query set, rather than a DoesNotExist exception.

The patch as proposed breaks 2 tests in the current suite, but the
error occurs in deletion code, so it's possible it's just a case of an
incomplete patch, rather than an outright problem.

The bigger problem is that the proposed change would change existing
API usage. I'm not quite ready to call it backwards-incompatible,
because our backwards-compatibility policy documents the fact that we
don't consider bugfixes to be a backwards incompatible change, and it
could be argued that this is bufix.

Providing additional wiggle room: the 'does it return None or raise an
exception' doesn't appear to be tested, and it isn't clearly
documented. This makes it much easier to argue that this is
undocumented and undesigned behavior.

The fact that this bug has existed for a long time without being
reported suggests that this isn't a high-traffic area of the API,
either, which means that the impact footprint of any change will be
smaller.

However, this isn't an area where only one opinion should matter. I'm
not comfortable making a judgement here without hearing the opinion of
others.



#14043 is clearly a bug to me (hence the accepted status). If I had to
guess at a cause, I'd say it's either:
 * The OneToOneField special case not being handled by deletion traversal
 * The related object cache on the o2o field not being cleared
correctly when null is assigned, causing the delete cascade to operate
on the older cached object.

The 'on delete set null' comment doesn't seem to be related here -- if
I've understood the ticket correctly, the relation has been broken by
'become_ghost()', so deletion shouldn't be cascading, regardless of
whether the relation implements ON DELETE CASCADE or not.



#14368 also strikes me as a bug, but it's one that's a little hard to
account for without some other changes.

In saying bob.soul = None, you then need to save the soul object in
order for the change to take effect. That isn't something that is
currently done. However, interestingly, it *is* done if you do the
analogous operation with a foreign key -- 

Re: AutoFields, legacy databases and non-standard sequence names.

[Hanne Moa]

On 7 October 2010 19:14, akaariai  wrote:
> Django doesn't expect the sequence name to be tablename_columname_seq,
> at least not in trunk. The last_insert_id method in backends/
> postgresql/operations.py uses select
> currval(pg_get_serial_sequence(tablename, columname)).
> pg_get_serial_sequence will return the correct sequence only if the
> sequence is owned by the tablename, columname combination. If you
> happen to have just one table per sequence, then issuing
> ALTER SEQUENCE sequencename OWNED BY tablename.columname;
> should fix the problem.

You can't necessarily do this with a legacy database, as other systems
also using that database expect the existing names.

I need to use my own backend because of posgresql's own
table-inheritance. Most tables in the db inherit from the same table
and inherits its primary key and the sequence for that primary key.
Then there are a few tables that inherits from a table that inherits
from the grandfather table that defines the primary key and its
sequence. So, I need to recursively discover the oldest ancestor of
each table and use the sequence of that ancestor.


HM

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Pylibmc Support: Part 2

[Russell Keith-Magee]

On Fri, Oct 8, 2010 at 10:09 AM, Jacob Burch  wrote:
> 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 Con that would need to be
> addressed before adequate pylibmc support was added into Django:
>
> * The suggested use of using query-string for client-specific options
> and libmemcached 'behaviors' eventually leading to massive client
> strings, and the use of a CACHE_SETTINGS dictionary may be a better
> solution.

CACHE_SETTINGS works for me. This also allows for options that aren't
strings, or can't be easily serialized as strings, or are painful to
URI-encode.

In the interests of fully supporting existing setups, we'll probably
need to do something like:

full_settings = ...parse options from CACHE_BACKEND string ...
if settings.CACHE_SETTINGS:
full_settings.update(settings.CACHE_SETTINGS)

but other implementation details than that, I'm +1.

> * Pylibmc 1.1 doesn't play that nice with mod_wsgi due to it's use of
> the Simplified GIL API (see: 
> http://www.dctrwatson.com/2010/09/beware-of-using-pylibmc-1-1-and-mod_wsgi/).
> Probably just need to make note of it in the documentation, but it's
> worth noting.
...
> * Because it isn't bound by the GIL, pylibmc by default isn't thread
> safe. There are a few different solutions, the most apparent being to
> use pylibmc's ThreadMappedPool. More info here:
> http://lericson.blogg.se/code/2009/september/draft-sept-20-2009.html
> and http://blog.sendapatch.se/2009/september/pooling-with-pylibmc-pt-2.html

Am I missing something, or aren't these variants of the same problem?

> Originally Myself and Noah Silas were working on a solution that would
> have two separate backends, one using of the ThreadMappedPool and one
> using the basic client. At this point, I think it's probably not even
> worth using one that uses the basic client, and having us keep one
> memached backend that can use multiple libraries (defaulting to python-
> memcached, and having initially pylibmc support as well.)
> ing.

I'm a little confused on the state of play here. If I'm understanding
this correctly:

 * In the simple/naive usage of the API ('basic client') pylibmc isn't
thread-safe, and therefore can't be used under mod_wsgi without
special configuration.

 * It is possible to use a ThreadMappedPool to access the pylibmc
client in a thread-safe way.

If this is the case, a ThreadMappedPool-based implementation sounds
like the only viable option; it doesn't strike me as a good idea for
Django to ship a cache backend that doesn't play well with mod_wsgi
without special configuration.

I'm also slightly unclear as to exactly what solution you're proposing. Is it:

 1) A completely new "pylibmc" backend implementing a ThreadMappedPool
interface (possibly inheriting from the memcached backend or a
factored base class)

 2) A revised import order inside the existing memcached backend that
would import pylibmc before or after attempted imports of cmemcache
and memcache

 3) A configuration option for the existing memcached backend that
controls which client library is used

The older mailing list thread seems to suggest (3) as the right
approach, but it isn't clear to me that this is still what you're
proposing.

Also, are there any API-level discrepancies remaining that need to be
considered? The earlier django-dev thread suggests that there are some
problems with get_multi(), but it also says that they've been fixed.
Is this the case?

Yours,
Russ Magee %-)

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: password is None in check_password

[Russell Keith-Magee]

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 now. Can someone indicate what we should
> accept as a password?

An empty string isn't a *good* password, but then neither is a single
character or a dictionary word, and we don't reject those. Policy
decisions like this aren't the domain of a web framework.

I'm sure there are also people using an empty password as the "I don't
actually want security" password. Plus, there's a history in the free
software community of using empty passwords as a protest [1] :-)

We can use None to mark an unusable password. Absent of a good
technical reason, I don't see why we should reject empty string.

As for the remainder of the patch on #14354 -- on the whole, it looks
good. I've put some review comments on the ticket.

[1] http://en.wikipedia.org/wiki/Richard_Stallman#Early_years

Yours,
Russ Magee %-)

-- 
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 options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.