Code

Opened 3 years ago

Closed 14 months ago

#16017 closed Bug (fixed)

createsuperuser fails if Python can't detect default locale

Reported by: prestontimmons Owned by: ramiro
Component: Core (Management commands) Version: 1.4
Severity: Normal Keywords: dceu2011
Cc: intelliyole, niels_bom, Chris.Wesseling@…, kmike84@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

Changeset r16182 introduced a get_system_username() function to the createsuperuser command.

This includes the lines:

try: 
    return getpass.getuser().decode(locale.getdefaultlocale()[1]) 
except (ImportError, KeyError, UnicodeDecodeError): 

If Python can't detect the default system locale, local.getdefaultlocale returns (None, None). This causes decode to raise:

TypeError: decode() argument 1 must be string, not None

Attachments (5)

16017.diff (1.4 KB) - added by prestontimmons 3 years ago.
Patch to call decode only if default locale is found.
ticket16017.patch (3.6 KB) - added by willhardy 3 years ago.
Added unit test for this fix
malformedlocale.diff (4.7 KB) - added by charstring 3 years ago.
malformedlocale2.diff (5.1 KB) - added by charstring 3 years ago.
mock getpass wasn't cleanup up
check_for_type_error.diff (697 bytes) - added by tbecker 21 months ago.
Just check for TypeError and be done with it

Download all attachments as: .zip

Change History (57)

Changed 3 years ago by prestontimmons

Patch to call decode only if default locale is found.

comment:1 Changed 3 years ago by aaugustin

  • Has patch set
  • Needs documentation unset
  • Needs tests set
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

This requires a test, which could be written like this:

locale.getdefaultlocale, old_getdefaultlocale = lambda: (None, None), locale.getdefaultlocale
try:
    # test here
finally:
    locale.getdefaultlocale = old_getdefaultlocale

comment:2 Changed 3 years ago by willhardy

  • Keywords dceu2011 added
  • Owner changed from nobody to willhardy
  • Status changed from new to assigned
  • UI/UX unset

comment:3 Changed 3 years ago by intelliyole

  • Cc intelliyole added

Changed 3 years ago by willhardy

Added unit test for this fix

comment:4 Changed 3 years ago by willhardy

  • Needs tests unset
  • Owner changed from willhardy to nobody
  • Status changed from assigned to new

comment:5 Changed 3 years ago by charstring

  • Patch needs improvement set

I think mocking both locale.getdefaultlocale and getpass is one mock to many.
This boils down to testing wether if statements work in python.
I'll attach a patch that also fixes the case of an unknown locale, that someone experienced today setting up his environment...

Though, I don't know whether this last case should be fixed, I suspect it only happens on misconfigured boxes.
But it does fit the title of the ticket.

Someone should check if these test should be skipped on non *nix environments.

Changed 3 years ago by charstring

comment:6 Changed 3 years ago by charstring

  • Easy pickings set

Just for the record... http://pastebin.com/fD4f8uVs contains the traceback of the usecase that happened to someone when having an incomplete or unknown locale.

It's on pastebin, so sprinters review this today! ;-)
In short, the issues are:

  • The discription of this ticket, describes the solution, not the problem. I'd like to see a usecase, before the solution goes in.
  • the usecase I introduced happened to someone at the sprints, but I'm not sure that it should be fixed; sometimes a traceback, google, fix your box is more helpful than a tool hiding a configuration problem on your box. (o perhaps that extra case shouldn't go in.
  • If we decide this should go in. It should be tested on different platforms and perhaps the tests should be skipped on a couple of them. (Anyone up for testing this on the Nintendo DS of their kid ;-)

Changed 3 years ago by charstring

mock getpass wasn't cleanup up

comment:7 Changed 3 years ago by charstring

Remco, you we're right about the mock getpass...

Fixed it in the new patch. All 3 points of my previous post still stand.

comment:8 follow-up: Changed 3 years ago by niels_bom

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly" without failing, I know it stumped me. Also: does a weird setting of locale actually cause any problems further down the road?

comment:9 Changed 3 years ago by niels_bom

  • Cc niels_bom added

comment:10 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by charstring

Replying to niels_bom:

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly" without failing, I know it stumped me. Also: does a weird setting of locale actually cause any problems further down the road?

Fair enough. So the point would be. Should we fallback silently and try to do the intended thing (quirksmode ;-)) or should we point out the problem in an error, because we might think to be able to interpret the intention, but the user could run into problems in the future.

I agree it's best we point out the problem nicely to have the user fix his environment and save him or her from future trouble.

Any suggestion on the phrasing of the error? Something along the style-guidelines of django errors. Do these exist?

comment:11 Changed 3 years ago by charstring

  • Cc Chris.Wesseling@… added

comment:12 Changed 2 years ago by kmtracey

#17022 reported this again and noted a specific OS where it happens.

comment:13 Changed 2 years ago by kmtracey

#17185 reported this again.

comment:14 Changed 2 years ago by nlsp

  • Cc niels.poppe@… added

I’ve posted #17185 — this is indeed happening when starting any session from an OSX terminal session, even on OS X 10.7.2.

However, having LANG unset, or set to a value a target host OS does not recognize should not be a requirement for running django — just check for a None encoding return and either give up (return an empty username) or try decode it (as ascii or UTF-8) and failing that, return empty.

This simple patch does just that. Please consider a simple fix to a simple problem.

Thanks.

comment:15 in reply to: ↑ 10 ; follow-up: Changed 2 years ago by nlsp

Replying to charstring:

Replying to niels_bom:

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly” …

Fair enough. So the point would be. Should we fallback silently and try to do the intended thing (quirksmode ;-)) or should we point out the problem in an error …

I agree it's best we point out the problem nicely to have the user fix his environment and save him or her from future trouble.


I disagree. It is no error to have no LANG defined in a terminal session. It is documented that locale.getdefaultlocale() can return (None, None).

It is a bug to pass it to decode() without checking. Possible friendly solution would be to say “we can’t work out your terminal character encoding, please enter your username”, but if it happens to be an ascii string that’s a bit silly, isn’t it?

Please default to ‘ascii’ or ‘UTF-8’ and handle UnicodeDecodeError as already implemented.

comment:16 in reply to: ↑ 15 Changed 2 years ago by charstring

Replying to nlsp:

Replying to charstring:

Replying to niels_bom:

In reaction to point 2 offered by charstring:
If there's a enviroment configuration problem I'd say it's more friendly to give that notice "We could not find a correct locale setting, please check whether your locale settings are configured correctly” …

Fair enough. So the point would be. Should we fallback silently and try to do the intended thing (quirksmode ;-)) or should we point out the problem in an error …

I agree it's best we point out the problem nicely to have the user fix his environment and save him or her from future trouble.


I disagree. It is no error to have no LANG defined in a terminal session. It is documented that locale.getdefaultlocale() can return (None, None).

True. But shouldn't getdefaultlocale return the C/POSIX locale in that case?
I tend to trust the Python core devs on checking this; if they can't figure out the default locale, who am I to assume I can do better?
If getdefaultlocale is broken, fix it in Python.

It is a bug to pass it to decode() without checking. Possible friendly solution would be to say “we can’t work out your terminal character encoding, please enter your username”, but if it happens to be an ascii string that’s a bit silly, isn’t it?

Perhaps. But we shouldn't be fixing problems at either the Python or the OS level.

Please default to ‘ascii’ or ‘UTF-8’ and handle UnicodeDecodeError as already implemented.

(None, None) means "Python can't figure out what the locale should be." I don't think I can do a better job. But feel free to use the testcase setup from my patch to complete your patch. This bickering about how to construct a proposed value the user can correct is pointless, but I find the lack of tests disturbing. ;-)

About the simplicity of the patch: This is hard to test. So the main code may be simple. The testcode, surely isn't. I think that tells us we're trying to fix a very low level problem.

comment:17 follow-up: Changed 2 years ago by chrish@…

This old bug report says that getdefaultlocale() shouldn't be used in new code; use getpreferredencoding() instead.

locale.getpreferredencoding() returns "US-ASCII" on my OS X laptop.

comment:18 in reply to: ↑ 17 Changed 2 years ago by chrish@…

Replying to chrish@…:

This old bug report says that getdefaultlocale() shouldn't be used in new code; use getpreferredencoding() instead.

locale.getpreferredencoding() returns "US-ASCII" on my OS X laptop.

Sorry, left out the URL: http://bugs.python.org/issue504219#msg8781

comment:19 follow-up: Changed 2 years ago by thomaslockhart1976@…

Any progress on this? chrish seems to have a solution. I see the problem on OSX Lion and I see blog reports that it has been seen on Ubuntu. Seems ripe for fixing...

comment:20 follow-up: Changed 2 years ago by dkdndes@…

I have echo $LANG with de_DE.UTF-8 and still get the problem. What would I need to change as a user (re your statement above - should we let the user fix the environment and prevent him from future problems)? Config: Lion 10.7.2 and python 2.7

comment:21 in reply to: ↑ 20 ; follow-up: Changed 2 years ago by anonymous

Replying to dkdndes@…:

I have echo $LANG with de_DE.UTF-8 and still get the problem. What would I need to change as a user (re your statement above - should we let the user fix the environment and prevent him from future problems)? Config: Lion 10.7.2, python 2.7., Django 1.4c2

Due to this error syncdb does not work properly with sqlite3 or mysql. I dont experience this problem with version 1.3.1.

comment:22 in reply to: ↑ 21 Changed 2 years ago by dkdndes@…

Replying to anonymous:

Replying to dkdndes@…:

I have echo $LANG with de_DE.UTF-8 and still get the problem. What would I need to change as a user (re your statement above - should we let the user fix the environment and prevent him from future problems)? Config: Lion 10.7.2, python 2.7., Django 1.4c2

Due to this error syncdb does not work properly with sqlite3 or mysql. I dont experience this problem with version 1.3.1.

de_DE.UTF-8 will not be recognised - if you change locale to UTF-8 it works in

def get_system_username(): 
    return getpass.getuser().decode(locale.getdefaultlocale()[1])

Hope the information helps to close the issue.

comment:23 in reply to: ↑ 19 Changed 2 years ago by anonymous

Replying to thomaslockhart1976@…:

Any progress on this? chrish seems to have a solution. I see the problem on OSX Lion and I see blog reports that it has been seen on Ubuntu. Seems ripe for fixing...

I've git the same problem under Django 1.4 and MacOS. Worked fine with Django 1.3 until yesterday. Would appreciate a bug fix or at least an idea for a work-around. Thanks.

comment:24 Changed 2 years ago by anonymous

I have the same problem, since updating to 1.4

comment:25 Changed 2 years ago by harm

This seems to be a regression in django 1.4

django 1.3.1 working ok
django 1.4

  File "/home/hnw/releases/dev/hnw/virtualenv/lib/python2.6/site-packages/django/contrib/auth/management/__init__.py", line 85, in get_system_username
    return getpass.getuser().decode(locale.getdefaultlocale()[1])
TypeError: decode() argument 1 must be string, not None

comment:26 Changed 2 years ago by anonymous

I confirm this for django 1.4.
Mac OS X 1.7.3

comment:27 Changed 2 years ago by anonymous

It helps running

$ export LANG="en_US.UTF-8"

comment:28 follow-up: Changed 2 years ago by anonymous

Assigned to: Nobody. Looks like it's not going to get fixed anytime soon... :( I hate having to maintain my own.

comment:29 in reply to: ↑ 28 Changed 2 years ago by ramiro

Replying to anonymous:

Assigned to: Nobody. Looks like it's not going to get fixed anytime soon... :( I hate having to maintain my own.

Wait, There is a way to spare you that feeling: Do you have a fix? Are you proud of it? Then why don't you add test and documentation and contribute it here as a patch? That would be w win for everybody.

One suggestion: Try to use your real name and not log in as an anonymous so if the fix gets committed we can give you proper credit. In general, we value that every interaction with this ticketing system be made by people using their real name.

comment:30 Changed 2 years ago by anonymous

Just to comment: I just ran into this. (clean, django 1.4, debian) THANKFULLY Googling the error led me here, but jeez - I had no IDEA where to look to fix something like this. Initial syncdb blew up, then I tried manually creating a superuser. This is ugly.

Running export LANG="en_US.UTF-8" on the shell before python manage.py createsuperuser *did* fix it for me.

Sorry I'm not submitting tests/patches, but wanted to add to confirmations that this exists, and crops up.

comment:31 Changed 2 years ago by anonymous

In OSX Lion using Django 1.4 I had the same error.

I fixed it by editing ~.profile and adding export LANG="en_US.UTF-8"

Then restart your terminal.

comment:32 Changed 2 years ago by anonymous

  • Version changed from SVN to 1.4

comment:33 Changed 2 years ago by anonymous

If you have LC_ALL in your environment you may need to run:

export LC_ALL="en_US.UTF-8"

in your shell as well.
At least that worked for me and just doing:

export LANG="en_US.UTF-8"

didn't work.

$ export LC_ALL="en_US.UTF-8" ;python -c 'import locale ; print locale.getdefaultlocale()'
('en_US', 'UTF-8')
$ 

Seems getdefaultlocale looks for many environment variables, in order, and use the first one it finds.


comment:34 follow-up: Changed 22 months ago by mrab54@…

Ran into this on FreeBSD 8.2.

Workaround:

$ echo 'setenv LANG en_US.UTF-8' >> ~/.cshrc

I don't see why this is required. Doesn't Django default to UTF-8? Or default to something?

comment:35 in reply to: ↑ 34 Changed 22 months ago by nlsp

  • Cc niels.poppe@… removed

Replying to mrab54@…:

Ran into this on FreeBSD 8.2.

Workaround:

[ platform specific shell commands ]

I don't see why this is required. Doesn't Django default to UTF-8? Or default to something?

The whole point is that getting the “username” will never be solved in a platform independent way.

Discussion about whether or not boxes are “misconfigured” when this happens are pointless. In my view is an error making Django depend on this.

One fix is to not try default to a username, another fix is to be more flexible in recovering from possible decoding errors.

Both are better than doing nothing. Or doing what is currently done: starting up a debate on how a ticket should be phrased and then doing nothing again.

Good luck!

comment:36 Changed 22 months ago by Chris Lawlor <lawlor.chris@…>

The question of whether or not to assume a default locale should perhaps be moved to a different ticket, or discussed on the developers mailing list. The problem at hand is that not checking for a return value of None when calling locale.getdefaultlocale() is a bug in Django code, and causes createsuperuser to blow up unexpectedly.

I think we can all agree that syncdb could fail more gracefully in this situation. I'm +1 on at least providing a helpful error message to the user which suggests setting one of 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', or 'LANG', though I'm not sure what the implication of returning an empty string for a username is, as in willhardy's patch.

comment:37 Changed 22 months ago by kmike

  • Cc kmike84@… added

comment:38 Changed 21 months ago by bill@…

Hey, I'm a Django newbie, so my judgement may not be sound. But I want to offer an opinion (or two...)

There are valid secondary questions about Django behavior and Python behavior regarding the default locale values. The primary question (to me) is this: There is a bug in Django, because the Django code does not check the validity of the expression it passes into decode(). What is the best way to fix it?

I suggest making a one-token change as follows. Add TypeError to the kinds of exceptions that are caught and handled at this point in the code:

  NEW  line 86:        except (TypeError, ImportError, KeyError, UnicodeDecodeError):

  PRESENT line 86:     except ( ImportError, KeyError, UnicodeDecodeError):

My thinking is that (1) the code is prepared to receive exceptions at this point, and gracefully recovers from them (see line 91), this is a reasonable workaround for the lack of checking of the argument to decode(), and (3) this fix allows manage.py and the tutorial to run without error.

---

In my opinion, it is crucially important that Django fix this ASAP. I really want to use Django, because people I respect say it is great. But the tutorial is dead in the water without a fix for this. And great code does not have a dead tutorial.

Changed 21 months ago by tbecker

Just check for TypeError and be done with it

comment:39 Changed 21 months ago by tbecker

  • Patch needs improvement unset

I'm running into this bug on OSX 10.7.4 and even though it's easy to fix by setting the environment variable, it's annoying, and would be very off-putting if this was my first go-round with Django.

If the system is not able to get a proper default locale and throws the TypeError, everything thereafter is perfectly satisfied dealing with the empty string as a return value. Patch I submitted ("check_for_type_error.diff") implements Bill's suggestion. It works for me after testing in a virtualenv, and is the simplest fix that could possibly work.

comment:40 follow-up: Changed 21 months ago by anonymous

[code]#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py syncdbcode fix create super user on FreeBSD 9.0

comment:41 in reply to: ↑ 40 Changed 21 months ago by anonymous

Replying to anonymous:

#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py syncdb fix create super user on FreeBSD 9.0, fist time syncdb, How to fix ready tis issue ?

comment:42 Changed 21 months ago by anonymous

This code, fix create super user on FreeBSD 9.0, fist time syncdb, How to fix ready tis issue ?

#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py syncdb

comment:43 Changed 21 months ago by anonymous

I must be ran the follow code, in order to add an superuser ready, after syncdb

server#env LANG=en_US.UTF-8 /usr/local/bin/python manage.py createsuperuser --username=superuser --email=superuser@mydomain

comment:44 Changed 21 months ago by leifdenby

Here's a simple patch. It might be better to just fail silently though as the default username is only presented as a help, and the warning I have added might just be confusing.

--- orig/django/contrib/auth/management/__init__.py	2012-07-26 14:48:31.000000000 +0200
+++ /usr/local/lib/python2.6/site-packages/django/contrib/auth/management/__init__.py	2012-07-26 14:49:39.000000000 +0200
@@ -82,7 +82,14 @@
         username could not be determined.
     """
     try:
-        return getpass.getuser().decode(locale.getdefaultlocale()[1])
+        default_encoding = locale.getdefaultlocale()[1]
+        if default_encoding == None:
+            print ("Warning: The default character encoding could not be "
+                "determined, it will be assumed that your local username "
+                "is encoded using UTF-8 (If you wish to use a different "
+                "please set the LANG environment variable).")
+            default_encoding = "UTF-8"
+        return getpass.getuser().decode(default_encoding)
     except (ImportError, KeyError, UnicodeDecodeError):
         # KeyError will be raised by os.getpwuid() (called by getuser())
         # if there is no corresponding entry in the /etc/passwd file

comment:45 Changed 21 months ago by anonymous

With leifdenby's path That's OK tks

Password (again):
Superuser created successfully.
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
server#

comment:46 Changed 21 months ago by cbarrick

Why are we using locale.getdefaultlocale()[1] instead of locale.getpreferredencoding() as chrish pointed out? (18)

For me locale.getpreferredencoding() returns a satisfactory encoding when locale.getdefaultlocale() returns (None, None).

>>> os.environ['LANG'] = 'en_US.UTF-8'
>>> locale.getdefaultlocale()
('en_US', 'UTF8')
>>> locale.getpreferredencoding()
'UTF-8'

>>> os.environ['LANG'] = ''
>>> locale.getdefaultlocale()
(None, None)
>>> locale.getpreferredencoding()
'US-ASCII'

getpreferredencoding does exactly what we want without a dependence on $LANG, so simply changing to that seems like the simplest and best solution.

comment:47 Changed 21 months ago by ramiro

  • Owner changed from nobody to ramiro
  • Status changed from new to assigned

comment:48 Changed 20 months ago by Ramiro Morales <cramm0@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In [4c934f3921a59c7b3e088f6472b6f6da40848567]:

Made createsuperuser more robust when getting current OS username.

Under some versions of OS X, failure in getting the default system
locale during the syncdb operation of the auth app were causing hard to
diagnose problems afterwards.

No solution based on getpreferredencoding() was chosen because it has
its own problems with certain combinations of Python and OS X versions
(e.g. http://bugs.python.org/issue6202).

Thanks prestonsimmons for the report and prestonsimmons and willhardy
for the initial patch.

Fixes #16017.

comment:49 Changed 15 months ago by bugs-django@…

  • Resolution fixed deleted
  • Status changed from closed to new

Still an issue:

sandbox@reactor webpymail % rm -r webpymail.db; LC_ALL=C LANG=C PYTHONPATH=..:$PYTHONPATH python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_admin_log
Creating table mailapp_useridentity
Creating table mailapp_userprofile
Creating table mailapp_folderstoexpand
Creating table mailapp_attachments
Creating table address_book

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Traceback (most recent call last):
  File "manage.py", line 37, in <module>
    execute_manager(settings)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 459, in execute_manager
    utility.execute()
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 382, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(*args, **options)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle
    return self.handle_noargs(**options)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive, db)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal
    interactive=interactive, db=db)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 73, in create_superuser
    call_command("createsuperuser", interactive=True, database=db)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/__init__.py", line 150, in call_command
    return klass.execute(*args, **defaults)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(*args, **options)
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle
    default_username = get_default_username()
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 105, in get_default_username
    default_username = get_system_username()
  File "/home/sandbox/.local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 85, in get_system_username
    return getpass.getuser().decode(locale.getdefaultlocale()[1])
TypeError: decode() argument 1 must be string, not None

Note that TypeError is raised, which is not on the list of handled exceptions.

Python 2.7.3

Django==1.4.3

The discription of this ticket, describes the solution, not the problem. I'd like to see a usecase, before the solution goes in.

The problem I see is that django produces an unhandled exception in a default configuration of FreeBSD (which does not set LANG environment variable).

This problem can be split into two sub-problems:

  1. Django refuses to work in a default configuration of FreeBSD.
  1. When django refuses to work, it does not provide user-friendly information on what needs to be done to make it work.

I disagree. It is no error to have no LANG defined in a terminal session. It is documented that locale.getdefaultlocale() can return (None, None).

It is a bug to pass it to decode() without checking. Possible friendly solution would be to say “we can’t work out your terminal character encoding, please enter your username”, but if it happens to be an ascii string that’s a bit silly, isn’t it?

Please default to ‘ascii’ or ‘UTF-8’ and handle UnicodeDecodeError as already implemented.

Agree with this.

I tend to trust the Python core devs on checking this; if they can't figure out the default locale, who am I to assume I can do better?

If you cannot figure out the default locale, and therefore are unable to determine how to interpret the username obtained by getuser(), why not take the except path and set the initial username to an empty string? Sounds like a better solution than preventing the user from being able to use django applications entirely.

https://code.djangoproject.com/attachment/ticket/16017/check_for_type_error.diff does fix the issue, although it is rather a hack. Instead the return value of getdefaultlocale should be checked before being used.

comment:50 Changed 15 months ago by bugs-django@…

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

1.5.x branch appears to implement setting to empty string on unknown locale.

comment:51 follow-up: Changed 14 months ago by ank.bnsl@…

  • Resolution fixed deleted
  • Status changed from closed to new

hi .
Current i am getting the above mentioned error .
Please find logs below :"
ankbansa-MacBookPro:acdb ankbansa$ python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table resultEntry_testcase
Creating table resultEntry_buildinfo
Creating table resultEntry_result
Creating table django_admin_log

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): y
Please enter either "yes" or "no": yes
Traceback (most recent call last):

File "manage.py", line 10, in <module>

execute_from_command_line(sys.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 443, in execute_from_command_line

utility.execute()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 382, in execute

self.fetch_command(subcommand).run_from_argv(self.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv

self.execute(*args, options.dict)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle

return self.handle_noargs(options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs

emit_post_sync_signal(created_models, verbosity, interactive, db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal

interactive=interactive, db=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send

response = receiver(signal=self, sender=sender, named)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 73, in create_superuser

call_command("createsuperuser", interactive=True, database=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 150, in call_command

return klass.execute(*args, defaults)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle

default_username = get_default_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 105, in get_default_username

default_username = get_system_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 85, in get_system_username

return getpass.getuser().decode(locale.getdefaultlocale()[1])

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 503, in getdefaultlocale

return _parse_localename(localename)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 435, in _parse_localename

raise ValueError, 'unknown locale: %s' % localename

ValueError: unknown locale: UTF-8
ankbansa-MacBookPro:acdb ankbansa$ python manage.py syncdb
Creating tables ...
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
ankbansa-MacBookPro:acdb ankbansa$ rm -f resources/sqlite.db
ankbansa-MacBookPro:acdb ankbansa$ python manage.py syncdb
Creating tables ...
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table resultEntry_testcase
Creating table resultEntry_buildinfo
Creating table resultEntry_result
Creating table django_admin_log

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Traceback (most recent call last):

File "manage.py", line 10, in <module>

execute_from_command_line(sys.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 443, in execute_from_command_line

utility.execute()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 382, in execute

self.fetch_command(subcommand).run_from_argv(self.argv)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv

self.execute(*args, options.dict)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle

return self.handle_noargs(options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs

emit_post_sync_signal(created_models, verbosity, interactive, db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal

interactive=interactive, db=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send

response = receiver(signal=self, sender=sender, named)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 73, in create_superuser

call_command("createsuperuser", interactive=True, database=db)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py", line 150, in call_command

return klass.execute(*args, defaults)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute

output = self.handle(*args, options)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle

default_username = get_default_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 105, in get_default_username

default_username = get_system_username()

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 85, in get_system_username

return getpass.getuser().decode(locale.getdefaultlocale()[1])

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 503, in getdefaultlocale

return _parse_localename(localename)

File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/locale.py", line 435, in _parse_localename

raise ValueError, 'unknown locale: %s' % localename

ValueError: unknown locale: UTF-8

This error message is wrong , showing error "unknown locale: UTF-8" to the user , conveys that the user has entered\put something wrong which is not the case here.
I facing the error for the first time . I have used Django on Pc but this my first experience of Django on Mac OSX (10.8.2) .

Please let me know in any case i can help .

comment:52 in reply to: ↑ 51 Changed 14 months ago by ramiro

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

Replying to ank.bnsl@…:

Please let me know in any case i can help .

Yes, one very useful piece of data would be what version of Django you are using.

The fix is available in the soon to be released 1.5. According to our work flow we mark a ticket fixed on this tracker when it has been fixed in the in-development version and not all of these fixes get applied to the already-released version (currently 1.4.x).

Unfortunately if you are using 1.4.x (latest stable release) you won't get this fix and will have to look for workaround/fixes provided by your OS.

Another option would be to start your exploration of Django by installing the first release candidate of 1.5.

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.