Am I reading this right as "people used to commonly solve this problem by using an internal API, but now we have a public one... AND the old internal API is now changed"?
If so, the solution seems obvious -- document that it's time to move the the official solution :) -- Curtis On 27 June 2014 21:04, Wim Feijen <[email protected]> wrote: > Hi Russ, > > Good point and thanks for testing! For me, this should definitely be > listed in the release notes and we should provide people a hint of how to > fix it as well. > > IMO we do not need to support a non-documented feature. > > Wim > > > > On Friday, 27 June 2014 07:58:27 UTC+2, Russell Keith-Magee wrote: >> >> Hi all, >> >> I've just done some testing of 1.7 against my 'day job' code base. The >> good news is that everything has pretty much worked out of the box without >> any problems. >> >> However, I did find one regression, which I've opened as #22915 [1]. Full >> details are on the ticket; the short version is that the API for >> Validation.update_error_dict() has changed in very subtle way. The change >> was introduced by [2], which introduced Form.add_error() [3]. >> >> The catch here is that ValidationError is definitely stable API, but >> update_error_dict isn't documented - so it isn't clear to me whether this >> should be considered a regression in a stable API that must be fixed, or a >> "backwards compatibility gotcha" that is worth some documentation, but not >> a code change. >> >> I caught the problem running the test suite for my "day job app". I'm >> doing some moderately complex form error handling, and in the `clean()` >> method for a form, I'm raising an error against a specific field on the >> field. This appears to be the exact use case that the `Form.add_error()` >> API is designed to satisfy, so the regression has been introduced by adding >> a formal API for something that people (including myself) would have been >> doing previously in an ad-hoc fashion. >> >> The question here is whether we need to continue to support the ad-hoc >> usage in a backwards compatible way. >> >> Thoughts? >> >> Yours, >> Russ Magee %-) >> >> [1] https://code.djangoproject.com/ticket/22915 >> [2] https://github.com/django/django/commit/ >> f563c339ca2eed81706ab17726c79a6f00d7c553 >> [3] https://code.djangoproject.com/ticket/20867 >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/841bccb0-3251-47e1-bc53-27413d052506%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/841bccb0-3251-47e1-bc53-27413d052506%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAG_XiSC9afJOUCuwT-%2B4_QncQ8OW_pLFsqH1E4Lfj3n2hHyTfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
