Re: [Django Code] #3148: Add getters and setters to model fields

[Django Code]

#3148: Add getters and setters to model fields
----------------------------------------+-----------------------------------
Reporter: je...@jerf.org | Owner: telenieko
Status: assigned | Milestone:
Component: Database wrapper | Version: SVN
Resolution: | Keywords:
Stage: Ready for checkin | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Comment (by Gulopine):

Doing some quick looking at this (I'll admit, I haven't applied it yet), I
came up with a 7-line utility function that handles everything the patch
does, but without touching core at all. If there's interest, I can post it
at djangosnippets, but I think there's something else to consider.

While the latest patch is a considerable cleanup from the original patch,
I think [http://groups.google.com/group/django-
developers/msg/c98281ddafe97aa3 one of the original author's
considerations] has been lost in translation. Again, I haven't applied it,
but it looks like it does exactly what my little utility function does,
and mine certainly suffers from the double-setter problem he describes.

Malcolm's [source:django/trunk/django/db/models/fields/subclassing.py
field subclassing work] does a good job of avoiding this, but it uses a
descriptor, which would interfere with the property, unless a new
descriptor is made that takes the double-setter issue *and* the property
stuff into account. Ultimately, I think it's a matter of providing the
simple, common case, like Malcolm did, and expecting those who need more
to know what they need. I don't know if that's enough for everybody, but
that's why I was working on a non-core option for this. I'd rather people
do a little hunting on the problem they have before they just pick a
"solution" that happens to be in core and get confused why it doesn't work
the way it should.

Of course, one other thing `SubfieldBase` takes into account is
serialization. Again, I haven't applied the patch or tested it out (I'm
heck-deep in other stuff at the moment), but I'm guessing there are going
to be some surprises, since I've run into a few things in the past when an
object's `__dict__` didn't line up with what some properties were
advertising. I'd certainly at least want to see that looked at by someone
who's passionate about this patch.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:19>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines

[Django Code]

#3148: Add getters and setters to model fields

---------------------------------------+------------------------------------

Reporter: je...@jerf.org | Owner: telenieko
Status: assigned | Milestone:
Component: Database wrapper | Version: SVN
Resolution: | Keywords:

Stage: Accepted | Has_patch: 1

Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |

---------------------------------------+------------------------------------
Changes (by serialx):

* stage: Ready for checkin => Accepted

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:20>

[Django Code]

#3148: Add getters and setters to model fields
---------------------------------------+------------------------------------
Reporter: je...@jerf.org | Owner: telenieko
Status: assigned | Milestone:
Component: Database wrapper | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------+------------------------------------

Changes (by terrex2):

* cc: terrex2 (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:21>

[Django Code]

#3148: Add getters and setters to model fields
---------------------------------------+------------------------------------
Reporter: je...@jerf.org | Owner: telenieko
Status: assigned | Milestone:
Component: Database wrapper | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------+------------------------------------

Comment (by telenieko):

The docs-refactor broke the patch, always up-to-date patch
[http://www.marcfargas.com/gitweb/?p=django.git;a=commitdiff;h=trac/3148
-field-properties;hp=master here in colours] and
[http://www.marcfargas.com/gitweb/?p=django.git;a=commitdiff_plain;h=trac/3148
-field-properties;hp=master raw]

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:22>

[Django]

#3148: Add getters and setters to model fields

---------------------------------------------------+------------------------

Reporter: je...@jerf.org | Owner: telenieko
Status: assigned | Milestone:

Component: Database layer (models, ORM) | Version: SVN

Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |

---------------------------------------------------+------------------------
Changes (by ramusus):

* cc: ram...@gmail.com (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:23>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: telenieko
Status: assigned | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------

Comment (by jacob):

I'm busy and don't have time to explain this fully. However, as a note to
myself and anyone who wants to try to channel my thinking, the syntax I'd
like here would look like::

{{{
class MyModel(Model):
foo = CharField(...)

@foo.getter
def get_foo(self):
...

@foo.setter
def set_foo(self, value):
...
}}}

I'll try to circle 'round back to this and explain more fully when I have
time.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:24>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------

Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:

Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0

Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Changes (by Gulopine):

* owner: telenieko => Gulopine
* needs_better_patch: 0 => 1
* status: assigned => new

Comment:

Replying to [comment:24 jacob]:

> I'm busy and don't have time to explain this fully. However, as a note
to myself and anyone who wants to try to channel my thinking, the syntax
I'd like here would look like

It seems simple enough to channel that, actually. I assume this would work
identically to the [http://docs.python.org/library/functions.html#property
new property methods] added in Python 2.6. I've been wondering about this
myself lately, but didn't spend the time to work on it because I forgot
this ticket already exists. I'll see what I can throw together this week.

I can think of a few questions that might need to be addressed along the
way (at least one that definitely will), but I'll hold off until I have
some working code before bringing them up. On a side note, if we mimic the
property methods, I assume we'd also want to include {{{@foo.deleter}}} as
well, which should be simple enough to throw in.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:25>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by Gulopine):

After doing some work on this, I'll throw in one particular comment about
naming. Python's built-in {{{@property}}} methods require that all the
methods have the same name, because things go pretty wonky if you don't.
They have their reasons, I'm sure, but I don't think that requirement
makes a lot of sense in our situation. Instead, I'm going with the (much
more obvious, IMO) approach of leaving any user-created methods in place
and updating the field object to work as a descriptor. In the context of
what a model definition looks like, I think that makes the most sense.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:26>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by blueyed):

I think this a fundamental feature, and although not fluent in Python and
Django, I've started working on it.

The proposed/attached patch implements the method suggested by jacob.

I've added tests for it and all the current tests still pass (there are
oddities with admin_scripts, but that's with and without the patch).

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:27>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by Alex):

Some feedback:

a) A decorator should always return a callable, in this case it should
return the original function (as Gulopine sugested), since the alternative
leaves None on the class, which is really awkward IMO.

b) As Gulopine suggested I think the better approach is to make the Field
object itself the descriptor when getter/setter/deleter are provided, not
a property object.

c) This should be handled by Field.contribute_to_class, not the Metaclass.

d) I'd like to see significantly more extensive tests, particularly with
things like:
* Providing only a subset of the available options.
* Providing a getter/setter with fields that have their own descriptor
(FileField and the RelatedFields). This I suspect may require a large
refactor of related.py, as Gulopine may have already found :)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:28>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1

Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Changes (by Alex):

* needs_docs: 0 => 1

Comment:

Oh, and

e) Documentation! :)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:29>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by blueyed):

Thanks for your feedback.
a) getter/setter/deleter now return the original function
b) I do not get this: using a decorator should make the object behave as
descriptor? Would that mean to have __get__/__set__/__del__ always, but
check there if a decorator should get called?
c) OK, moved. Much better. It took me a while to come that close already
though.. ;)
d) 1. This should fail, at least when going the property route, my
understanding is that you need to define all, otherwise the field is e.g.
not writable. This would be different when using descriptors only, of
course.
2. Only fields derived from Field are supported currently. FileField
does not come through Field - at least that's what my testing shows.
Should they get handled?
e) I think the other points should get worked out before.. :)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:30>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by Alex):

The reason you aren't seeing FileField/RelatedFields working right now is
that they provide their own descriptor, which overwrites yours I imagine.
This is why Gulopine and I discussed integrating the descriptor into the
Field itself (and only conditionally attaching it to the class) and then
integrating the existing descriptors for Files and related objects into
the class itself so everything works together correctly. You can find our
discussion of this here: http://botland.oebfare.com/logger/django-
dev/2009/12/6/1/#22:41-1918558 (extends onto the next page).

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:31>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Comment (by Alex):

Thanks for all your work on this BTW!

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:32>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by blueyed):

FileField/RelatedFields work as before (at least passing tests - I have
not tried it for real) - they are not affected by getter/setter currently
(AFAICS).

My understanding had been that I'm not using a descriptor, but
property/ies instead - I've just read that it's considered to be a
descriptor, too.

The discussion you've linked sounds good, but still I'm not sure where
you're heading.. :)

Therefore, a last patch from me (which does not use property() anymore),
but adds a FieldDescriptor class. There's a lot to fix/straighten for
sure, but just to get this out for discussion.

I'll now wait until Gulopine and others provide some feedback on this.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:33>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by jerf):

Using the model:

{{{
class GetSet(models.Model):
field = models.CharField(max_length=200)

@field.setter
def field_setter(self, value):
self._field = value + "_test_transform"
@field.getter
def field_getter(self):
return self._field
}}}

we obtain with the latest patch "django-3148-approach-via-
descriptors.diff" the following python REPL output:

{{{
Python 2.6.4 (r264:75706, Nov 8 2009, 19:34:30)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from mysite.modeltest.models import GetSet
>>> example = GetSet(field = "test")
>>> example.field
'test_test_transform'
>>> example.save()
>>> example.id
1
>>> del example
>>> example = GetSet.objects.get(id = 1)
>>> example.field
u'test_test_transform_test_transform'
>>> example.save()
>>> del example
>>> example = GetSet.objects.get(id = 1)
>>> example.field
u'test_test_transform_test_transform_test_transform'
>>>
}}}

That is not shippable behavior. The setter must not apply during
construction from a database load. Loading and immediately saving an
object with no changes must be a no-op, in terms of the stored data.
Anything else is asking for disaster.

I find myself wondering if perhaps the traffic on this bug is telling us
that the interaction of properties when the values are being backed by a
database store is just too complicated a concept to be worthwhile. When
the setters and getters would apply is more subtle than it first appears,
and perhaps "simple enough that it works as it first appears" (i.e., "no
property behavior") is a better idea.

I am not being sarcastic or passive aggressive. I am seriously wondering
this. I now think the documentation would have to explain this in more
detail than I originally thought, which adds a chunk of complexity right
where Django's documentation needs it least, and I'm no longer convinced
that's worth it. (Plus, after reviewing the latest SVN code, I still do
not see a way to do this correctly without setting the flag during
construction like I did in my original patch, which was not an...
''appreciated'' addition to the model loading code.)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:34>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by semenov):

Wrong. Lack of a correct implementation does '''not''' mean the initial
problem doesn't worth solving it. Logically, the desired behaviour is
simple as hell - do not run setters/getters when Django does its ORM
things (that is: object fetching, construction, saving, deleting, caching,
etc.), but always call getters/setters when a model is used from from an
external (business logic) code. I don't see anything strange or hard or
inconsistent from the architectural point of view either. The ORM - which
is aware of the essence of the models - should work with the data directly
using internal structures (!__dict!__ or whatever), and all the other
unaware code should be using the "frontend" properties.

The "simple enough that it works as it first appears" approach is
ultimately doomed. If everyone was adopting this kind of thinking, there
would be no ORM at all and we'd be running manual SQL queries which are
"simple enough that they work as they first appear". Abstractions always
leak and there will always be trade-offs, but that doesn't mean we should
stop creating them. We should only stop when the gain is less than the
cost, which is clearly not the case for getters and setters.

By the way, I am more and more thinking that the part of the confusion
comes from that everyone is talking about BOTH getters and setters. In my
opinion, '''we should have only setters'''. As the data is backed by a
database, ''reading'' should always return what the database actually
holds (with respect to Field.to_python(), of course). However, ''setting''
is different and needs to be able to be overriden indeed - because that
allows to implement additional validation, transformation (e.g. proper
formatting), and other things like logging.

One of the clear examples is using Model Forms. Right now, the whole
powerful concept is barely useful for any non-trivial models, because you
can't just call modelform.save() and expect it to call all setters
properly -- instead, you always have to code all that manually. However, I
can't imagine any example where a ''getter'' would be of any use.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:35>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Comment (by semenov):

I beg my pardon for not reading the "simple enough that it works as it
first appears" sentence clearly. I'm taking my words back. Of course, the
things should work as they appear. That just doesn't mean we can't achieve
that behavior with custom setters. :)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:36>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Changes (by Guilherme Gondim (semente) <sem...@taurinus.org>):

* cc: semente+dj...@taurinus.org (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:37>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Gulopine
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Changes (by erikrose):

* cc: erikrose (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:38>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------

Reporter: je...@jerf.org | Owner: Alex
Status: assigned | Milestone:

Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Changes (by Alex):

* owner: Gulopine => Alex
* status: new => assigned

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:39>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Alex
Status: assigned | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Changes (by chrischambers):

* cc: chrischambers (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:40>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner: Alex
Status: assigned | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Comment (by josh.s...@gmail.com):

One of my pet peeves is that Django models are almost always used as
simple data containers. This is true for many frameworks and technologies
though. What is wrong with defining methods on the class explicitly that
are responsible for setting the correct fields, where there is logic
associated with them? Allow the users of the model to decide whether they
call the documented api of the model, or go directly to the fields.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:41>

[Django]

#3148: Add getters and setters to model fields
---------------------------------------------------+------------------------
Reporter: je...@jerf.org | Owner:

Status: new | Milestone:

Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------

Changes (by Alex):

* owner: Alex =>

* status: assigned => new

Comment:

Unassigning, I haven't had the time to work on this.

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:42>

[Django]

#3148: Add getters and setters to model fields

--------------------------------------------------------+-------------------
Reporter: jerf@… | Owner:

Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:

Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 |
--------------------------------------------------------+-------------------
Changes (by denilsonsa):

* cc: denilsonsa@… (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:43>

[Django]

#3148: Add getters and setters to model fields
--------------------------------------------------------+-------------------
Reporter: jerf@… | Owner:
Status: new | Milestone:
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 |
--------------------------------------------------------+-------------------

Changes (by EnTeQuAk):

* cc: EnTeQuAk (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:44>

[Django]

#3148: Add getters and setters to model fields

-------------------------------------+-------------------------------------
Reporter: jerf@… | Owner:
Type: New | Status: new
feature | Component: Database layer
Milestone: | (models, ORM)
Version: SVN | Severity: Normal

Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0

Patch needs improvement: 1 | Easy pickings: 0
-------------------------------------+-------------------------------------
Changes (by noah):

* cc: noah (added)
* easy: => 0

--
Ticket URL: <http://code.djangoproject.com/ticket/3148#comment:46>