Code

Opened 3 years ago

Closed 3 years ago

#15404 closed (wontfix)

"from __future__ import unicode_literals" in "settings.py"

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:

Description

good day!

if: in file my_web_site/settings.py 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:

  • DATABASES
  • SECRET_KEY

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

but Django-documentation say that:
Django natively supports Unicode data everywhere. (http://docs.djangoproject.com/en/dev/ref/unicode/)

thanks!

Attachments (3)

ERRORS-settings.py (3.5 KB) - added by plm_tower39 3 years ago.
error-test-output.txt (60.3 KB) - added by plm_tower39 3 years ago.
NO-ERRORS-settings.py (3.6 KB) - added by plm_tower39 3 years ago.

Download all attachments as: .zip

Change History (5)

Changed 3 years ago by plm_tower39

Changed 3 years ago by plm_tower39

Changed 3 years ago by plm_tower39

comment:1 Changed 3 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 3 years ago by lrekucki (previous) (diff)

comment:2 Changed 3 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.