Remove blank spaces with strip when validating the data

[Marinho Brandão]

Would be nice if forms remove blank spaces with .strip() method when validating data[] to cleaned_data (or saving).

[bp@…]

There is a ticket #4960: 'Add "strip" keyword argument to CharField constructor' that was closed as "wontfix - it's too specialized for inclusion in the main library.", which I personally find quite baffling since it looks like a really low-impact 4-line change, and IMHO for the vast majority of field inputs in a form - you probably don't want leading or tailing spaces.

When prompting for a city name for example, do you really want people entering "Chicago " or " Chicago" instead of just "Chicago"? That hardly seems like a specialized need.

[David Cramer]

I'm signing this petition. Every single use-case we have of a Char or Text field would use strip() as a default before validation.

[jamiequint]

+1 here. Seems obvious that in most form cases this should be the default. I don't want users to be able to bypass form fields simply by entering spaces in the required fields instead. Isn't it more common to want stripped data than not? I imagine this probably won't be changed to be like this for backwards compatibility sake, but it does seem to make the most sense, no?

[Antti Kaihola]

#6717 is about URL fields and leading/trailing spaces specifically.

[Karen Tracey <kmtracey@…>]

I agree this would be useful. Greg Fuller has raised the issue on django-users and pointed out several ways ordinary users can get tripped up and cause problems when blanks are not stripped:

​http://groups.google.com/group/django-users/browse_thread/thread/ad01501c1fd9d213#

[Johannes Dollinger]

How about a more general normalize keyword?

CharField(normalize=lambda x: x.strip()) or CharField(normalize=lambda x: x.upper())

That could also be used to accept "+2h" or "yesterday" in DateTimeFields, or expressions for numerical fields, or ..

[Johannes Dollinger]

normalize kwarg for newforms.Field

[Johannes Dollinger]

BooleanField.__init__() looks messy.

[bruno.desthuilliers@…]

As far as I'm concerned, I'd even say that all (text) fields should be stripped by default, period.

[zhango]

+1 on this too please. In usability tests, most of my users accidentally entered a space in EmailFields and were baffled when the django-based system threw an error at them, since what they typed looks fine to them. This happens too often not to be addressed.

[nail.xx <nail.xx@…>]

+1 vote. Strip should be performed by default.

[nail.xx <nail.xx@…>]

Possible temporary solution is available at ​http://www.djangosnippets.org/snippets/956/. But I'm still sure strip should be done by django as default behavior.

[Julian Bez]

+1. Could be made opt-out, if someone really doesn't like it.

[Malcolm Tredinnick]

Will everybody please stop putting "+1" style comments. They are *totally* useless for the purposes of the ticket. Even if 100 people added such a comment, that's less than .1% of the userbase, so is entirely non-representative. The resolution will be on the merits, not some straw count.

[Ivan Giuliani]

See also #5714 that basically belongs to this.

[dc]

-1 for the normalize(). It's overkill for simple stripping. And for complicated normalization better normalize data in form.clean_FIELD() or write own field subclass with specialized clean() method.

[Ole Laursen]

I sometimes got email from visitors claiming that the user registration form didn't work as it didn't accept their email address. Took quite a while to figure out what was wrong. Today I discovered the same problem with the shopping cart.

Adding a clean_email() method to the form to strip the data doesn't work as it is run after EmailField does its check. So it's easy to do the wrong thing, and it's not straightforward to fix.

[Marinho Brandão]

In my opinion would be simple have an attribute "keep_blank_spaces" in forms.CharField, with defaulf value False. Then who wants to keep the blank space just set something like this:

    field = forms.CharField(max_length=20, keep_blank_spaces=True)

I'm sure most of cases people don't want keep blank spaces at left or right of cleaned strings.

[Julian Bez]

Replying to marinho:

I'm sure most of cases people don't want keep blank spaces at left or right of cleaned strings.

That might be, but as everyone here was told "Even if 100 people [think so], that's less than .1% of the userbase, so is entirely non-representative. The resolution will be on the merits, not some straw count."

I'm wondering when that is happening.

[Marinho Brandão]

@julianb

When I said "most of cases" I wasn't meaning "most of us in this discussion", but "most of projects made using Django". And for exceptional cases, there would be an attribute to set it.

[Farhan Ahmad]

I am also looking for a decision on this (ideally, yes, do it). Posting to the django developers group for a decision (​http://groups.google.com/group/django-developers/t/90352cc0da78390b).

[Henk de Vries]

2 years after opening this ticket still no decision? Rails' ticket management is way, way better than Django's.

[Harro]

If you call another ticket a duplicate: ​http://code.djangoproject.com/ticket/11907
At least make sure the original is still looked at...

[James Bennett]

1.2 is feature-frozen, moving this feature request off the milestone.

[ishirav]

Two and a half years for such a small change? C'mon guys, this really needs to be fixed.

Here's another use case that would benefit from this: you send an email to a user with his initial password, or an application license key. When the user copies the value from their email into a form field on your site, very often an extra blank slips in and the form validation fails. This is especially problematic in password fields, since the user can't even see that there's an extra blank in there. It happened to me several times, because when you select-by-double-clicking a word in Firefox or Thunderbird, the blank after the word is included in the selection (try it!)

[Julien Phalip]

Tests need to be updated to use unit tests.

[Anders Hovmöller]

Spaces in various fields in the database screw up sorting too, which gets reported as bugs because the spaces are of course not even shown by HTML.

It's also very hard to fix after the fact. Cron jobs that run strips on all character fields on all your models? No thanks :P

[Ramiro Morales]

Replying to boxed:

Easy picking is a recently added nullable boolean-like flag for tickets in our Trac instance that is reset to false with the first update to the ticket after it got added. That is the reason it changes even when you hadn't deactivated it explicitly. There is no need to set it back to on.

[Alex Kamedov]

update to current trunk

[Alex Kamedov]

Strip leading and trailinig whitespace for CharFields

[Jacob]

Silently discarding user input -- whether it's spaces or not -- isn't something a framework ought to do. There are enough ways to do this in user code, but if Django strips spaces there aren't any way to get them back, so it's gotta stay this way.

I'd be slightly in favor of a normalization callback for fields (as suggested above), or maybe some sort of "strip spaces" flag (but only if done is a reasonable manner. If someone has a good proposal (hopefully with a patch) here feel free to open a new ticket for it.

[anonymous]

It is really error prone to do the stripping manually. This should be reconsidered.

[Mike Fogel]

FWIW, I agree with @jacob's decision that by default the framework shouldn't be mucking with user input. However, since removing leading/trailing whitespace is the desired behavior for I believe most every (every?) form I've ever written... a 'strip spaces' flag would be helpful.

[Jon Dufresne]

+1. I would really appreciate if this feature could be reconsidered. Whether it is on by default or not, I don't care. Users are bypassing form validation by entering spaces in required fields. This seems to throw away the entire point.

[Tom Christie]

Link to latest thread on the discussion group regarding this...

​https://groups.google.com/d/msg/django-developers/D1GBj9VB9sk/gDm5PFHMKSUJ