My guess, for whatever it's worth, is that the debugger is evaluating
the errors property before the form is bound, causing self._errors to be
populated with an empty ErrorDict. If so, the state revealed by the
debugger is not an accurate reflection of the code as it would normally
execute.
On 09/20/2011 04:46 PM, Jacob G wrote:
I doubt I'm familiar enough with Django to fix bugs.
I am puzzled by what I am see though with the BaseForm class in Aptana
PyDev debugger. I noticed that full_clean() was not being called via a
call to is_valid. So I stepped through the debugger, and for some
strange reason, the BaseForm constructor, although the code says
"self._errors = None" the debugger watchlist shows self._errors as set
to an empty ErrorDict, and therefore the _get_errors() method never
called full_clean().
Does this make any sense? It doesn't sound right.
On Sep 20, 4:17 pm, Shawn Milochik<sh...@milochik.com> wrote:
On Tue, Sep 20, 2011 at 4:14 PM, Jacob G<ja...@fareclock.com> wrote:
Thanks, I didn't realize errors is property that calls _get_errors().
Yeah, it's non-obvious. That's one of the nice things about
open-source, though. You can go through the code and understand how
your tools work so you can better apply them.
Side-note -- now that you're browsing Django's code, I think you could
easily participate by going to the Trac instance and closing a few
easy tickets. ;o) https://code.djangoproject.com/
Shawn
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
