> 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. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/f62ee326-11a8-447b-a19c-3028b6e7453f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
