Thanks for your explanations, now I understand better how it works. I
updated my fix to store the to_python() values in the instances
__dict__ and it works perfectly.
I don't see other ways to improve that patch, do I have to wait for a
review or can I set the ticket ready for checkin myself ?
L
On Nov 26, 2007 11:40 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> I regret not having a recent trunk to test this with, but I think
> you'd be better off storing th evalue in the object's namespace
> dictionary instead. I've recently outlined[1] how this works, and you
> can also see a great e
I regret not having a recent trunk to test this with, but I think
you'd be better off storing th evalue in the object's namespace
dictionary instead. I've recently outlined[1] how this works, and you
can also see a great example of it in GeoDjango[2], also linked from
that article.
Essentially, r
I realized my patch may introduce a memory leak : as I understand what's
going on in django.db.models.fields.subclassing, Creator().value becomes
a class attribute for custom field classes that have SubfieldBase as
their __metaclass__, which leads to the problem illustrated in my unit test.
Stori
