Remove blank spaces with strip when validating the data

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.

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.

+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?

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

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#

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 ..

normalize kwarg for newforms.Field

BooleanField.__init__() looks messy.

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

+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.

+1 vote. Strip should be performed by default.

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.

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

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.

See also #5714 that basically belongs to this.

-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.

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.

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.

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.

@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.

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).

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

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

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