On Wednesday 04 February 2015 11:00:50 Tom Christie wrote: > > it will be backwards incompatible for every Django installation out > > there, but also because throwing away data that the user actually entered > should be an opt-in, not opt-out behavior. > > If adequately called out I think there'd be a valid case that the current > and future issues it'll be causing to applications right now would outweigh > the risk of compatibility breakages. I can see a couple of cases where I > might not want stripped whitespace, but only in slightly contrived and edge > case situations. > > Validating and normalizing input at the field level in a way that supports > the common case by default seems like a good plan to me. I'm not sure I see > any great difference between a user entering "3.1" in an integer field and > having 3 returned is so very different from having "hello " return "hello" > on a char field. And we're not of course throwing anything away at the > `request.POST` or `Form` layer - it's only once we're validating an > individual field that the normalization is being applied. > > I don't have an great investment in this either way around, but I think > it's a valid user-focused improvement worth considering *if* someone > actually puts together a pull request for it.
I agree with this as well; I'd argue, though, that there is a difference between leading and trailing whitespace. Leading whitespace is usually visible and, to my mind, much more likely to be intentional. Shai.
