Quick update:
When the lines were removed, self.errors would raise AttributeError.
Instead of removing the lines, I changed them to:
if name == "errors":
# Call the Django errors @property
return super().errors
This seems to work very well.
It also seems like the lines may originally have been added because
someone was running into that AttributeError?
Returning None would solve that problem, but not actually be "correct" to
my mind (leading for example to the bug we were experiencing).
So maybe my change above constitutes a bugfix?
- Ben
On Monday, August 28, 2017 at 12:32:37 PM UTC-7, B AG wrote:
>
>
> Hello all!
>
> I'm working on a project which derives from Cartridge.
> One of our Forms has a __getattr__ which was ultimately copy-pasted
> from cartridge.shop.forms.FormsetForm a while back.
> (
> https://github.com/stephenmcd/cartridge/blob/master/cartridge/shop/forms.py#L215
> )
> It starts with these 2 lines:
>
> if name == "errors":
> return None
>
> The result being that form.errors is always None, regardless of the
> value of form._errors.
> But Django's Form.is_valid() consists of:
>
> return self.is_bound and not self.errors
>
> So already that looks like it would cause bugs; but the behaviour we're
> experiencing is even stranger.
> Specifically, given a freshly bound instance of our Form subclass, we
> get the following behaviour:
>
>
> form.is_valid() # True
> form.is_valid() # False
> form.is_valid() # False
> form.is_valid() # False
> # etc...
>
>
> Stepping through with pdb, the "reason" is that in the first call to
> is_valid(), self.errors is resolving to self.__getattr__('errors'), while
> in subsequent calls to is_valid(), self.errors is resolving to the
> Form.errors @property.
> Why self.errors is resolving differently, I don't know. (Python magic
> T__T)
> For now I'm just trying to understand the purpose of those 2 lines -- I
> would love to just remove them.
> There is no comment in that function explaining them, and the commit in
> which they were introduced doesn't mention them:
>
>
> commit 2eb573be9a38f190e4633fdc94fcd7bd50ce5565
> Author: stephenmcd <[email protected]>
> Date: Tue Apr 6 11:12:46 2010 +1000
>
> Total rewrite of the checkout process after hitting a variety of
> limitations with Django's FormWizard. Now supports going backwards through
> process as well as configuring the number of steps in the checkout process
> from 1 to 3 via settings.
>
>
> Any insight would be appreciated. Thanks!
> - Ben
>
>
--
You received this message because you are subscribed to the Google Groups
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
