When I start Python from Mac OS' Terminal.app, python recognises the encoding as UTF-8:
$ python3.0
Python 3.0.1 (r301:69556, May 18 2009, 16:44:01)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.encoding
'UTF-8'
This works the same for python2.5.
But inside Emacs, the encoding is US-ASCII.
Python 3.0.1 (r301:69556, May 18 2009, 16:44:01)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.encoding
'US-ASCII'
How do I make Emacs communicate with Python so that sys.stdout knows to use UTF-8?
Edit: Since I don't have the rep to edit the accepted answer, here is precisely what worked for me on Aquaemacs 1.6, Mac OS 10.5.6.
In the python-mode-hook, I added the line
(setenv "LANG" "en_GB.UTF-8")
Apparently, Mac OS requires "UTF-8", while dfa says that Ubuntu requires "UTF8".
Additionally, I had to set the input/output encoding by doing C-x RET p and then typing "utf-8" twice. I should probably find out how to set this permanently.
Thanks to dfa and Jouni for collectively helping me find the answer.
Here is my final python-mode-hook:
(add-hook 'python-mode-hook
(lambda ()
(set (make-variable-buffer-local 'beginning-of-defun-function)
'py-beginning-of-def-or-class)
(define-key py-mode-map "\C-c\C-z" 'py-shell)
(setq outline-regexp "def\\|class ")
(setenv "LANG" "en_GB.UTF-8"))) ; <-- *this* line is new
check your environment variables:
$ LANG="en_US.UTF8" python -c "import sys; print sys.stdout.encoding"
UTF-8
$ LANG="en_US" python -c "import sys; print sys.stdout.encoding"
ANSI_X3.4-1968
in your python hook, try:
(setenv "LANG" "en_US.UTF8")
Related
When I start a python interactive session from the command line I am greeted by :
Python 3.9.6 (default, Jun 30 2021, 10:22:16)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
Is there a way of disabling that message so that I go immediately to the >>> prompt?
Yes, there is a way to do so.
Type in the cmd:
python -q
instead of
python
and this should do the trick.
On my Linux machine, directly execute python command, it shows that my Python is UCS4 build.
Python 2.7.3 (default, Jan 8 2018, 17:43:28)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> if sys.maxunicode > 65535:
... print 'UCS4 build'
... else:
... print 'UCS2 build'
...
UCS4 build
However, when I call python in C++ program using
Py_Initialize();
PyRun_SimpleString("import sys");
PyRun_SimpleString("if sys.maxunicode > 65535:\n print 'UCS4 build'\nelse:\n print 'UCS2 build'");
it prints "UCS2 build".
Other information from the python called by c++ are:
platform:Linux-2.6.32_1-19-0-0-x86_64-with-centos-6.3-Final
('Python', '2.7.5 (default, Apr 13 2016, 14:25:24)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]')
('Python', '******/venv')
I have double checked the python executable path. They are from the same path, but python version and gcc version are different.
Anyone know the reason of this strange sympotom?
Well, I solved this problem. Using ldd command, I found that libpython2.7.so.1.0 pointed to a wrong default path, not the one printed before. Correct the LD_LIBRARY_PATH solved this confusion.....
I am using virtualenv to run a script that uses subprocess popen to run another program that requires the system wide python and original environment variables. How do I prevent virtualenv from affecting it?
You can pass in a modified PATH for the subprocess with env=.
from subprocess import Popen
from os import environ
from os.path import join as path_join
myenv = environ.copy()
if 'VIRTUAL_ENV' in environ:
myenv['PATH'] = ':'.join(
[x for x in environ['PATH'].split(':')
if x != path_join(environ['VIRTUAL_ENV'], 'bin')])
Popen(['command', '--with', 'arguments'], env=myenv)
virtualenv creates a copy of python executable and you can activate it to your current shell:
This will change your $PATH so its first entry is the virtualenv’s
bin/ directory. (You have to use source because it changes your shell
environment in-place.) This is all it does; it’s purely a convenience.
If you directly run a script or the python interpreter from the
virtualenv’s bin/ directory (e.g. path/to/ENV/bin/pip or
/path/to/ENV/bin/python-script.py) there’s no need for activation.
So when I've activated python in a virtualenv for my project it's the one that will be used:
gonczor#wiktor-papu:~/Projects/papukurier/papukurier$ source ../venv/bin/activate
(venv) gonczor#wiktor-papu:~/Projects/papukurier/papukurier$ which python
/home/gonczor/Projects/papukurier/venv/bin/python
(venv) gonczor#wiktor-papu:~/Projects/papukurier/papukurier$ python
Python 2.7.14 (default, Sep 23 2017, 22:06:14)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.executable
'/home/gonczor/Projects/papukurier/venv/bin/python'
>>>
But at the same time you can give full path to execute any other python instance on your computer:
(venv) gonczor#wiktor-papu:~/Projects/papukurier/papukurier$ /usr/bin/python
Python 2.7.14 (default, Sep 23 2017, 22:06:14)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.executable
'/usr/bin/python'
>>>
I believe subprocess doesn't care about you venv
subprocess.run('/path/to/system/python program.py', stdout=PIPE, stderr=PIPE)
When I type "python" and return in shell, the following lines will come out:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
How to surpress these lines please?
An easy way is to call Python as python -i -c "". This will also disable any start-up scripts, though. If you have a start-up script, you can also use python -i ~/.pythonrc.py (or however that script is named).
So today I upgraded to bazaar 2.0.2, and I started receiving this message (I'm on snow leopard, btw):
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.
very strange, since my LANG is actually empty. Similar thing happen when I try to tinker with the locale module
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
exporting LANG does not help
sbo#dhcp-045:~ $ export LANG=en_US.UTF-8
sbo#dhcp-045:~ $ 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.
However, this solved the problem
sbo#dhcp-045:~ $ export LANG=en_US.UTF-8
sbo#dhcp-045:~ $ 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')
Could you please explain what's going on here, for better googlability ?
2016 UPDATE: Turns out that this is a Python bug since at least 2013, very probably earlier too, consisting in Python not reacting well to non-GNU locales - like those found in Mac OS X and the BSDs. The bug is still open as of September 2016, and affects every Python version.
If there was no LANG environment variable set, chances are you had either an LC_CTYPE (the key variable) or LC_ALL (which overrides if set) environment variable set to UTF-8, which is not a valid OS X locale. It's easy enough to reproduce with the Apple-supplied /usr/bin/python or with a custom python, as in your case, that was built with the 10.6 SDK (probably also the 10.5 SDK). You won't be able to reproduce it that way with a python.org python; they are currently built with the 10.4 SDK where the locale APIs behave differently.
$ 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:
There may be another piece to the puzzle. A quick look at the bzr 2.0.1 I have installed indicates that the message you cite should only show up if locale.getpreferredencoding() raises a locale.Error. One way that can happen is if the python _locale.so C extension can't be loaded and that can happen if there are permission problems on it. For example, MacPorts currently is known to have problems setting permissions if you have a customized umask; I've been burned by that issue myself. Check the permissions of _locale.so in the python lib/python2.5/lib-dynload directory and ensure it is 755. The full path for MacPorts should be:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/
I faced the same problem. When I ran locale, I noticed that the LANG and LC_ALL were unset. So I fixed this by adding the following lines in the .bash_profile file:
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
Then I simply ran:
source ~/.bash_profile
And this issue was fixed thereafter on my Mac.
It's a Mac OS X problem. To see your locale settings, run locale in terminal. locale -a should list all locales that you have defined (that you may use as argument to LC_ALL).
Notice that LC_ALL and other LC_* variables take precedence over LANG when defined.