On 06/27/2014 06:41 AM, Russell Keith-Magee wrote: > > On Fri, Jun 27, 2014 at 7:35 PM, Curtis Maloney > <cur...@acommoncreative.com <mailto:cur...@acommoncreative.com>> wrote: > > 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 :) > > > Broadly speaking, I agree. However, my hesitation in categorically > agreeing stems from the fact that ValidationError *is* public API. Or, > at least, the constructor is, - but it seems a little absurd that we > formally document a way for people to construct an object, but not to > support any of the ways that they might have *used* that object.
I don't think there's any absurdity. The documented and supported way to "use" ValidationError has always been to simply raise it from a clean() or clean_field() method, in which case Django itself catches it. Calling other undocumented methods on it it is clearly making use of unsupported internal API. I think Curtis is right, there is no problem with breaking use of the undocumented API and documenting the new public API to achieve the same thing. Carl
signature.asc
Description: OpenPGP digital signature
