#19807 closed Bug (fixed)
Creating a superuser doesn't work
| Reported by: | Florian Sening | Owned by: | Claude Paroz |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | dev |
| Severity: | Release blocker | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
When syncdb asks if it should create a superuser it fails right after the password.
TypeError: must be char, not unicode
Attachments (1)
Change History (14)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
| Component: | Uncategorized → Core (Management commands) |
|---|---|
| Severity: | Release blocker → Normal |
We have no sufficient information to set the release blocker flag, unless more details are provided.
comment:3 by , 13 years ago
I'm running Django master on Windows 7 with Python 2.7.2 - traceback is as follows:
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 240,
in run_from_argv
self.execute(*args, **options.__dict__)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 283,
in execute
output = self.handle(*args, **options)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 413,
in handle
return self.handle_noargs(**options)
File "C:\Python27\lib\site-packages\django\core\management\commands\syncdb.py"
, line 109, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db)
File "C:\Python27\lib\site-packages\django\core\management\sql.py", line 195,
in emit_post_sync_signal
interactive=interactive, db=db)
File "C:\Python27\lib\site-packages\django\dispatch\dispatcher.py", line 182,
in send
response = receiver(signal=self, sender=sender, **named)
File "C:\Python27\lib\site-packages\django\contrib\auth\management\__init__.py
", line 117, in create_superuser
call_command("createsuperuser", interactive=True, database=db)
File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line
161, in call_command
return klass.execute(*args, **defaults)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 283,
in execute
output = self.handle(*args, **options)
File "C:\Python27\lib\site-packages\django\contrib\auth\management\commands\cr
eatesuperuser.py", line 125, in handle
password2 = getpass.getpass('Password (again): ')
File "C:\Python27\lib\getpass.py", line 95, in win_getpass
msvcrt.putch(c)
TypeError: must be char, not unicode
I guess this is a Windows-only problem. I'll investigate further.
comment:4 by , 13 years ago
Just wanted to note that this seems to be a Windows-only and non-Django problem.
The error occurs if you use unicode_literals in conjunction with a custom prompt for getpass.
from __future__ import unicode_literals
import getpass
password = getpass.getpass()
password2 = getpass.getpass('Password (again): ')
comment:5 by , 13 years ago
| Severity: | Normal → Release blocker |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
Django should use force_str on the prompt before calling getpass.
Marking as a release blocker again since it appears to be related to unicode_literals, which is a change in 1.5.
comment:6 by , 13 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
by , 13 years ago
| Attachment: | 19807-1.diff added |
|---|
follow-up: 9 comment:8 by , 13 years ago
I dug into the issue just a little bit further. The problem is that getpass does not support Unicode yet (because it doesn't use the Unicode methods of msvcrt). While this is clearly a Python bug it got introduced during the transition of Django from Python 2.x to Python 3.x - hence I too consider it a release blocker.
But I'm not sure about the fix. What happens when getpass gets fixed? Will it break again? Will the test fail? I would prefer a fix that makes Unicode available as soon as this gets fixed.
I can't test the patch right now. Anybody else able to test it?
comment:9 by , 13 years ago
Replying to Semmel:
But I'm not sure about the fix. What happens when getpass gets fixed? Will it break again? Will the test fail? I would prefer a fix that makes Unicode available as soon as this gets fixed.
force_str is converting to bytestring on Python 2, and let the string Unicode on Python 3, so I think we should be safe on this side.
comment:10 by , 13 years ago
Sounds good + the tests run fine. And of course - this fixes the issue. Great work. :)
comment:12 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Could you please tell us:
--tracebackoption