I'm certainly leaning on the side of "strip by default" because, like many others, I feel it's the expected default -- users just don't get it -- and have been bitten by it before.
I think I'll have a PR for this later tonight... -- Curtis On 5 February 2015 at 14:23, charettes <charett...@gmail.com> wrote: > Like Russ I think this should be at the form level. > > Since both db.CharField and db.TextField use a form.CharField the > stripping implementation should be done there. > > I commented here because I recently fixed a related bug in an application > I maintain where a trailing white-space was not striped from an URLField > form input. Since browsers automatically strip trailing white-space in urls > (e.g. href=" example.com/path " == href="example.com/path") the anchor in > the widget we provide was pointing to the correct resource when clicked by > the user. However, when our system appended a querystring (By using the > urllib and urlparse modules) for analytics purposes (e.g "example.com/path > ?param=value") the white-space ended up making the whole URL invalid since > the "/path " lead to a 404. > > Simon > > Le mercredi 4 février 2015 21:25:02 UTC-5, Collin Anderson a écrit : > >> Hi All, >> >> I'd be ok with a well thought-out strip-by-default. >> >> - I think most of my problems have been with trailing whitespace on >> CharFields. >> - I once have seen a minor unintentional leading whitespace. I think I >> also may have once used a leading whitespace for sorting purposes, but I'd >> be ok with even having leading whitespace stripped by default. >> >> I can't think of many cases where trailing whitespace has been an issue >> for TextFields. Has this been an issue for people? I could imagine some >> people would want a trailing newline on TextFields. However, peeking at >> what other frameworks do, I'd be ok with this by default too :) >> >> Also, did we decide if the Model-field-layer or Form-field-layer would be >> better? >> >> Collin >> >> On Wednesday, February 4, 2015 at 5:51:30 PM UTC-5, Shai Berger wrote: >>> >>> 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. >>> >> -- > 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/ff91cec7-90a2-4db3-8747-97d333ad218b%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/ff91cec7-90a2-4db3-8747-97d333ad218b%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 (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/CAG_XiSAEDZtXnSCf7tRzJ-R8h%3Dv7xT84krifCOs9MsJZHBqisw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
