2009-12-02 15 views
28

Así que hoy he actualizado a 2.0.2 bazar, y empecé a recibir este mensaje (estoy en leopardo de las nieves, por cierto):python locale error extraño. ¿Qué está pasando aquí exactamente?

bzr: warning: unknown locale: UTF-8 
    Could not determine what text encoding to use. 
    This error usually means your Python interpreter 
    doesn't support the locale set by $LANG (en_US.UTF-8) 
    Continuing with ascii encoding. 

muy extraño, ya que mi LANG está realmente vacía. Algo similar sucede cuando trato de jugar con el módulo Locale

Python 2.5.4 (r254:67916, Nov 30 2009, 14:09:22) 
[GCC 4.3.4] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import locale 
>>> locale.getdefaultlocale() 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
    File "/Users/sbo/runtimes/lib/python2.5/locale.py", line 443, in getdefaultlocale 
    return _parse_localename(localename) 
    File "/Users/sbo/runtimes/lib/python2.5/locale.py", line 375, in _parse_localename 
    raise ValueError, 'unknown locale: %s' % localename 
ValueError: unknown locale: UTF-8 

exportar LANG no ayuda

[email protected]:~ $ export LANG=en_US.UTF-8 
[email protected]:~ $ bzr 
bzr: warning: unknown locale: UTF-8 
    Could not determine what text encoding to use. 
    This error usually means your Python interpreter 
    doesn't support the locale set by $LANG (en_US.UTF-8) 
    Continuing with ascii encoding. 

Sin embargo, esto resuelve el problema

[email protected]:~ $ export LANG=en_US.UTF-8 
[email protected]:~ $ export LC_ALL=en_US.UTF-8 

Python 2.5.4 (r254:67916, Nov 30 2009, 14:09:22) 
[GCC 4.3.4] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import locale 
>>> locale.getdefaultlocale() 
('en_US', 'UTF8') 

Podría explicar lo que está pasando aquí, para una mejor googlability?

+0

¿Alguna otra información sobre su problema? –

+0

+1 las dos líneas de "exportación" hicieron que mi "ValueError: localidad desconocida: ..." desapareciera. – Bogatyr

+0

Muchas gracias por esas dos últimas líneas. Me salvó y estoy seguro de que muchos otros usuarios de Mac tienen mucho tiempo. –

Respuesta

16

2016 ACTUALIZACIÓN: Resulta que this is a Python bug desde al menos 2013, muy probablemente también antes, que consiste en que Python no reacciona bien a entornos locales que no son GNU, como los que se encuentran en Mac OS X y BSD. El error sigue abierto desde septiembre de 2016 y afecta a todas las versiones de Python.


Si no había LANG entorno de conjunto de variables, lo más probable es que tenía ya sea un LC_CTYPE (la variable clave) o LC_ALL (que anula si se ha ajustado) variable de entorno establece en UTF-8, que no es un local OS X válida . Es bastante fácil de reproducir con el /usr/bin/python suministrado por Apple o con un pitón personalizado, como en su caso, que fue creado con el SDK 10.6 (probablemente también el SDK 10.5). No podrá reproducirlo de esa manera con python.org python; en la actualidad están construidos con el 10.4 SDK donde las API locales se comportan de manera diferente.

$ unset LANG 
$ env | grep LC_ 
$ export LC_CTYPE="UTF-8" 
$ /usr/bin/python # Apple-supplied python 
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import locale ; locale.getdefaultlocale() 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py", line 459, in getdefaultlocale 
    return _parse_localename(localename) 
    File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/locale.py", line 391, in _parse_localename 
    raise ValueError, 'unknown locale: %s' % localename 
ValueError: unknown locale: UTF-8 
^D 
$ /usr/local/bin/python2.6 # python.org python 
Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import locale ; locale.getdefaultlocale() 
(None, 'mac-roman') 
>>> 

EDIT:

Puede haber otra pieza al rompecabezas. Un vistazo rápido al bzr 2.0.1 que he instalado indica que el mensaje que cita solo debe aparecer si locale.getpreferredencoding() levanta un locale.Error. Una forma de que esto suceda es que la extensión C de Python _locale.so no se puede cargar y eso puede suceder si hay problemas de permisos en ella. Por ejemplo, actualmente se sabe que MacPorts tiene problems setting permissions if you have a customized umask; Me he quemado con ese problema yo mismo. Compruebe los permisos de _locale.so en el directorio python lib/python2.5/lib-dynload y asegúrese de que sea 755. La ruta completa para MacPorts debería ser:

/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/ 
+0

La pitón soy el uso se instala a mano, no es la instalación estándar de Python incluida con OSX. Además, parece que no tengo _locale.so o _locale.dylib .... uh? –

+0

Debe haber un _locale.so en lib-dynlib. De lo contrario, su python no se creó correctamente en OS X y locale.py recurrirá a algunos comportamientos predeterminados. –

+0

@NedDeily, parece que ahora sabe mejor que lo que muestra esta respuesta, ya que dio una muy buena explicación en https://bugs.python.org/issue18378#msg215215. Tal vez podrías arreglar tu respuesta? (Para googlability, como el OP preguntó) – hmijail

4

Es un problema de Mac OS X. Para ver su configuración regional, ejecute locale en la terminal. locale -a debe enumerar todas las configuraciones regionales que haya definido (que puede usar como argumento para LC_ALL).

Observe que LC_ALL y otras variables LC_* tienen prioridad sobre LANG cuando están definidas.

+0

Más específicamente, este es un problema con el entorno, no solo con Mac OS X. Linux y otros clones de UNIX son propensos a los mismos problemas si personaliza su entorno y desaparece inadvertidamente. A veces los problemas aparecen de inmediato y otras veces hasta que realmente los necesitas para trabajar. Otro síntoma de tener demasiadas formas de hacer lo mismo ... – jathanism

+1

@synack: Esto es algo que ha surgido antes con OS X, por lo que * No * creo que es porque Stefano cambió su entorno. – u0b34a0f6ae

+0

@ kaiser.se: ¿Por qué crees que es un problema y por qué con OS X? Tener un conjunto LC_CTYPE o LC_ALL explica el comportamiento visto por el OP y está funcionando según lo documentado. El ejemplo que proporcioné falla exactamente de la misma manera en un sistema Debian Linux actual, con la excepción de que el nuevo bash en ese sistema en realidad lo advierte al exportar LC_CTYPE al valor inválido "UTF-8". –

1

Tuve el mismo problema. Cuando ejecuté locale, noté que LANG y LC_ALL estaban desarmados.Así que me fijo esto añadiendo las siguientes líneas en el archivo .bash_profile:

export LC_ALL=en_US.UTF-8 
export LANG=en_US.UTF-8 

Entonces me encontré simplemente:

source ~/.bash_profile 

Y este problema se solucionó a partir de entonces en mi Mac.

Cuestiones relacionadas