Opened 6 years ago

Closed 6 years ago

#15404 closed (wontfix)

"from __future__ import unicode_literals" in ""

Reported by: Andrej A Antonov (at Tower-39) <plm.tower39@…> Owned by: nobody
Component: Uncategorized Version: 1.2
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


good day!

if: in file my_web_site/ to insert line:

from __future__ import unicode_literals

than: command...

python2.6 -m my_web_site.manage test

....showing many many many many errors (errors related to unicode)

at least that errors related with parameters:


(this parameters no-error only in byte-strings, but not unicode)

but Django-documentation say that:
Django natively supports Unicode data everywhere. (


Attachments (3) (3.5 KB) - added by plm_tower39 6 years ago.
error-test-output.txt (60.3 KB) - added by plm_tower39 6 years ago. (3.6 KB) - added by plm_tower39 6 years ago.

Download all attachments as: .zip

Change History (5)

Changed 6 years ago by plm_tower39

Changed 6 years ago by plm_tower39

Changed 6 years ago by plm_tower39

comment:1 Changed 6 years ago by lrekucki

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Not all of those errors are related to unicode - most of them should disappear on lastest 1.2.X version. I runned Django's full test suite with SECRET_KEY being unicode and DATABASES containing unicode keys and only errors I get are related to SECRET_KEY. IMHO, there is nothing to fix here, because SECRET_KEY should be a byte-string - after all it's a series of random bytes. (Well, ok - maybe a docfix and a sanity check on startup).

Could you provide an easy way to reproduce an error related to DATABASES setting ?

Last edited 6 years ago by lrekucki (previous) (diff)

comment:2 Changed 6 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

We natively support unicode, but we don't natively support Python 3 (at least, not yet). The {{future}} call you describe exists specifically as a Python 3 migration aid.

This will become a legitimate bug when we actually claim some level of Python 3 support, but until then, I'm going to mark this wontfix.

Note: See TracTickets for help on using tickets.
Back to Top