Opened 16 years ago
Closed 16 years ago
#12645 closed (wontfix)
UnicodeEncodeError when validating forms with non-ascii field names
| Reported by: | Alan Justino da Silva | Owned by: | unbracketed |
|---|---|---|---|
| Component: | Forms | Version: | 1.1 |
| Severity: | Keywords: | unicode | |
| Cc: | alan.justino@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
I am creating forms dynamically, so users can type field names.
Django is raising UnicodeEncodeError when some field name has a non-ascii name. Is simple not acceptable to constrain users to ASCII only.
Baked example:
class UtilizacaoForm(forms.Form):
pass
ut = UtilizacaoForm()
ut.fields[u'Diâmetro'] = forms.CharField(max_length=3)
ut.is_valid()
File "django/forms/forms.py" in is_valid
120. return self.is_bound and not bool(self.errors)
File "django/forms/forms.py" in _get_errors
111. self.full_clean()
File "django/forms/forms.py" in full_clean
242. if hasattr(self, 'clean_%s' % name):
Exception Type: UnicodeEncodeError at /novakoski/modelos/detalhe/1/
Exception Value: ('ascii', u'clean_Di\xe2metro', 8, 9, 'ordinal not in range(128)')
Occurs because hasattr(obj, str) can't handle non-ascii at str, before preparing to call clean_fieldname.
Bug found at 1.1.1 (r11612), but stays alive at actual TRUNK (r12264).
Original traceback paste: http://dpaste.com/hold/147583/
Quick fix added.
Attachments (1)
Change History (6)
by , 16 years ago
| Attachment: | bugfix.diff added |
|---|
comment:1 by , 16 years ago
| Summary: | UnicodeEncodeError when validating forms with non-ascii names → UnicodeEncodeError when validating forms with non-ascii field names |
|---|
comment:2 by , 16 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 16 years ago
| Patch needs improvement: | set |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
Patch doesn't cover all cases. For example, printing a form created with the same conditions (dynamically added field with a non-ASCII name) will also generate an exception.
comment:4 by , 16 years ago
Replying to unbracketed:
Patch doesn't cover all cases. For example, printing a form created with the same conditions (dynamically added field with a non-ASCII name) will also generate an exception.
Isn't this because of console encoding issues?. My console is configured to UTF-8, as seen:
alanjds@lgpill:~$ locale LANG=pt_BR.UTF-8 LANGUAGE=pt_BR: pt: en_US: en LC_CTYPE="pt_BR.UTF-8" (...) LC_ALL="pt_BR.UTF-8"
When locale config was set as LANG=C, printing from ipython or simple python console throws exceptions yet.
Could you post an example? I would like to try to reproduce this error.
comment:5 by , 16 years ago
| milestone: | 1.2 |
|---|---|
| Resolution: | → wontfix |
| Status: | assigned → closed |
In general I agree that it's not acceptable, but that's partly a limitation of Python itself. You can't use non-ascii values for python variables, so you can't create model fields, or declaratively create form fields with non-ascii values. What you're doing here is essentially a hack to get around that fact. You can still change the label of the field to "Diâmetro" if you want.
Bugfix - use a try-catch to workarround hasattr ASCII limitation