How can I set the default language of the Gtk3 Stock Buttons to another language?
I tried:
sudo apt-get install language-pack-en language-pack-gnome-en
But:
import locale
from pprint import pprint
pprint(locale.getlocale(locale.LC_ALL))
locale.setlocale(locale.LC_ALL, 'en_EN.utf8')
response:
('de_DE', 'UTF-8')
Traceback (most recent call last):
File "tp_tools.py", line 41, in <module>
locale.setlocale(locale.LC_ALL, 'en_EN.utf8')
File "/usr/lib/python2.7/locale.py", line 581, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
Working on Linux Mint 18 with Python 2.7 and Gtk3
en_EN.utf8 and also en_EN is no valid locale (contrary to de_DE). You can list your installed locales with locale -a in your shell.
A correct locale would be for example en_US or en_GB. And a correct instruction would be locale.setlocale(locale.LC_ALL, 'en_US').
The problem is that gi.repository.Gtk calls Gtk.init() while being imported, and after that it is nearly impossible to make any changes to localization. Furthermore, setting the locale to hardcoded strings makes your application almost unportable, since the only locale you can assume to exist is "C", which doesn't even include UTF-8 support.
The only solution I found so far is by setting the environment variable 'LANGUAGE' before any import of GLib modules, which is given priority by gettext and does not need to have an encoding definition appended to it (more information). This works for me:
import os
os.environ["LANGUAGE"] = "en"
PS: Stop using Python 2, it's outdated.
PPS: Gtk+ 3 stock buttons are deprecated.
Related
I have installed yapf and the PyYapf package (https://github.com/jason-kane/PyYapf) for sublime text for Python code formatting.
Furthermore, for my Python projects I'm using pipenv.
When executing the formatting command in sublime I receive the following error
Traceback (most recent call last):
File "~/.pyenv/versions/3.6.8/bin/pipenv", line 10, in <module>
sys.exit(cli())
File "~/.pyenv/versions/3.6.8/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
File "~/.pyenv/versions/3.6.8/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 696, in main
_verify_python3_env()
File "~/.pyenv/versions/3.6.8/lib/python3.6/site-packages/pipenv/vendor/click/_unicodefun.py", line 124, in _verify_python3_env
' mitigation steps.' + extra
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Consult https://click.palletsprojects.com/en/7.x/python3/ for mitigation steps.
This system supports the C.UTF-8 locale which is recommended.
You might be able to resolve your issue by exporting the
following environment variables:
export LC_ALL=C.UTF-8
export LANG=C.UTF-8
I have now tried the suggestion to use the two above exports and set them globally in my profile (and reboot).
Opening a terminal and checking they seem to be available:
$printenv | grep "C.UTF-8"
LC_ALL=C.UTF-8
LANG=C.UTF-8
However, sublime text still gives the original error. Looking at the source of the package the environment is read in like this inside the PyYapf.py package:
self.popen_env = os.environ.copy()
When printing the content of self.popen_env then the LANG and LC_ALL don't seem to be set or not to the C.UTF-8 value.
Where is sublime text getting the envs from?
Quick workaround:
$ cd ~/.config/sublime-text-3/Packages
$ mkdir -p Default
$ echo 'import os; os.environ["LC_ALL"] = os.environ["LANG"] = "C.UTF-8"' > Default/echo.py
Well, for God's sake, DO NOT try this nasty hack. Please take some time to setup your locales properly, otherwise you will likely encounter more locale problems in the future.
For Linux Mint & other Debian variants, simply run $ sudo dpkg-reconfigure locales, and tick off en_US.UTF-8 (or any other locale that you prefer) on the list. Follow these two posts for more details about locale errors.
Im trying to compile Godot engine following the instructions here
When I run scons bin/godot as the tutorial says, I get the following error:
scons: Reading SConscript files ...
ImportError: cannot import name _args_from_interpreter_flags:
File "/home/grayfox/github/godot2/godot/SConstruct", line 9:
import multiprocessing
File "/usr/lib64/python2.7/multiprocessing/__init__.py", line 65:
from multiprocessing.util import SUBDEBUG, SUBWARNING
File "/usr/lib64/python2.7/multiprocessing/util.py", line 40:
from subprocess import _args_from_interpreter_flags
The SConstruct file starts this way:
EnsureSConsVersion(0,14);
import string
import os
import os.path
import glob
import sys
import methods
import multiprocessing
...
If I try to run python SConstruct I get an error complaining about missing functions defined by scons (i.e. the script fails after doing all the imports).
Commenting import multiprocessing fixes the issue but I don't want to modify that file, as I would have to revert the change if I ever make a pull request. The project is quite active so I believe this has something to do with my local configuration.
Any ideas why the script is failing to import _args_from_interpreter_flags only if I execute it via scons?
[UPDATE]
I did a fresh Gentoo install and the problem persists. I did some tests and I found this:
In a python terminal>
>>> import SCons.Script
>>> from subprocess import _args_from_interpreter_flags
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name _args_from_interpreter_flags
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/site-packages/SCons/compat/_scons_subprocess.pyc'
But the output is different if I do this:
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/subprocess.pyc'
So I update my question: Is this a bug? Can anybody reproduce it in other distros? If it's a bug, should I report it to Gentoo or to SCons?
[ANOTHER UPDATE]
Adding temp.extend([os.path.join(x, 'lib64') for x in prefs]) did't work, same error.
Adding print sys.path at the beginning of the compact module gives:
['/usr/lib64/python-exec/python2.7/scons-local-2.3.0',
'/usr/lib64/python-exec/python2.7/scons-local',
'/usr/lib64/python2.7/site-packages/lib32/scons-2.3.0',
'/usr/lib32/scons-2.3.0',
'/usr/local/lib32/scons-2.3.0',
'/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons-2.3.0',
'/usr/lib/python2.7/site-packages/scons-2.3.0',
'/usr/local/lib/python2.7/site-packages/scons-2.3.0',
'/usr/lib64/scons-2.3.0',
'/usr/lib64/python2.7/site-packages/lib32/scons',
'/usr/lib32/scons',
'/usr/local/lib32/scons',
'/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons',
'/usr/lib/python2.7/site-packages/scons',
'/usr/local/lib/python2.7/site-packages/scons',
'/usr/lib64/scons',
'/usr/lib64/python2.7/site-packages/RBTools-0.6-py2.7.egg',
'/usr/lib64/python27.zip',
'/usr/lib64/python2.7', #It's here, so what's the problem?
'/usr/lib64/python2.7/plat-linux2',
'/usr/lib64/python2.7/lib-tk',
'/usr/lib64/python2.7/lib-old',
'/usr/lib64/python2.7/lib-dynload',
'/usr/lib64/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/gtk-2.0',
'/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode']
It looks as if this isn't really a problem connected to SCons directly. You might have an alien "subprocess" module/package installed in your system. Also check out Cannot import name _args_from_interpreter_flags which seems to be related.
Based on your updated question: I tried to compile Godot on my machine (Python 2.7.3, SCons 2.3.1, Ubuntu 12.04 LTS) and it's running fine, so the problem is not related to the provided SConstruct (and its supporting build description files in subfolders). The "_scons_subprocess" module gets used only when the import of the original "subprocess.py" fails. So I suspect that the SCons start script sets up a wrong sys.path, which may happen under 64bit (see issue http://scons.tigris.org/issues/show_bug.cgi?id=2657 ).
After you added "temp.extend([os.path.join(x, 'lib64') for x in prefs])", your "print sys.path" statement shows paths like "/usr/lib64/python-exec" in its output. A Google search turned up the page http://forums.gentoo.org/viewtopic-t-985402-start-0.html for me. It describes an issue with Gentoo, where programs are installed as links to pip. Please follow the given advice and see if this fixes your problem.
It's a bug in Gentoo's scons-2.3.0 and scons-2.3.1 ebuilds (see bug report). It has been fixed in versions 2.3.1-r1 and higher.
I'm trying to set GST_PLUGIN_PATH environment variable before loading custom gstreamer plugin in an integration test, so I need to change GST_PLUGIN_PATH programmatically.
But without GST_PLUGIN_PATH set in shell, gst.element_factory_make fails.
I'm using gstreamer-0.10, python2.6 and linux 3.2.0 (debian 6).
Example:
import gst, os
os.environ['GST_PLUGIN_PATH'] = '/tmp'
print gst.element_factory_make('myelem')
Without GST_PLUGIN_PATH set in shell:
$ export GST_PLUGIN_PATH=
$ ./gstpathtest.py
Traceback (most recent call last):
File "./gstpathtest.py", line 7, in <module>
print gst.element_factory_make('myelem')
gst.ElementNotFoundError: myelem
With GST_PLUGIN_PATH set in shell:
$ GST_PLUGIN_PATH=/tmp ./gstpathtest.py
/MyElem:myelem0 (__main__.MyElem)
or with GST_PLUGIN_PATH exported in shell:
$ export GST_PLUGIN_PATH=/tmp
$ ./gstpathtest.py
/MyElem:myelem0 (__main__.MyElem)
When run with GST_DEBUG=6 I noticed that myelem gets created but is immediately unref-ed and destroyed, which is probably the cause of the error.
I even tried to add the path to os.environ['PATH'], or directly to sys.path but it didn't change anything.
My main question is: am I doing something wrong on python-level (and what exactly) or does it indicate some bug in the myelem plugin itself?
Oh, stupid me - if I set os.environ['GST_PLUGIN_PATH'] before importing gst, everything works as expected.
Also, gst.registry.scan_path works:
import gst
gst.registry_get_default().scan_path('/tmp')
print gst.element_factory_make('myelem')
UPDATE 10 Secs later
Fixed properly now, and thanks to JF and Gauden.
UPDATE
I have found a temporary fix by saving the IDLE file in the directory the other working file is in. (I would still like to know how to fix it entirely if I can.)
That's not a permanant fix, so if you want to try and help make it work wherever the file is saved, feel free.
This is the start of a python file:
#!/usr/bin/python
# -*- coding: utf-8 -*-
import wikipedia
import pagegenerators
import sys
import re
import pywikibot
from pywikibot import *
(You may have noticed it's a pywikipedia script, but I think that's irrelevent)
This file runs fine from the command line.
However, when I try and use IDLE to develop the script, or just use the IDLE interpreter, I get an error:
>>> import wikipedia
Traceback (most recent call last):
File "<pyshell#9>", line 1, in <module>
import wikipedia
ImportError: No module named wikipedia
I don't really have a clue why it isn't working.
I have also tried this:
>>> imp.find_module("wikipedia.py","f:/ake/pa/th/")
Traceback (most recent call last):
File "<pyshell#7>", line 1, in <module>
imp.find_module("wikipedia.py","f:/ake/pa/th/")
ImportError: No frozen submodule named f:/ake/pa/th/.wikipedia.py
The path given in the error log is the correct path to the wikipedia.py file, there's just that . before wikipedia.py.
I then tried adding the path to sys.path, but that didn't work either:
>>> import sys
>>> sys.path.append("c/users/adam/py")
#the same error...
Path to the module: `c:\users\joe_bloggs\py\wikipedia.pyc
Python executable: Command line:C:\Python27\python.exe, IDLE: C:\Python27\pythonw.exe
PYTHONPATH throws, in both:
Traceback (most recent call last):
File "<pyshell#20>", line 1, in <module>
print os.environ['PYTHONPATH'].split(os.pathsep)
File "C:\Python27\lib\os.py", line 423, in __getitem__
return self.data[key.upper()]
KeyError: 'PYTHONPATH'
OS: Windows 7
Python version: 2.7.2
A new PATH: IDLE, and Command Line:
C:\Program Files\Common Files\Microsoft Shared\Windows Live
C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live
C://Python27
C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin
C:\Program Files (x86)\QuickTime\QTSystem\
C:\Program Files (x86)\Windows Live\Shared
EDIT The answer to the above question proved to be fairly simple, but I am editing this answer as a possible troubleshooting checklist for future reference, and as a checklist for others who may need to prepare questions of this nature in the future.
CLUE 1: What is the path to the module you are importing?
>>> import wikipedia
>>> print wikipedia.__file__
This will give you the path to the compiled module, and is one clue.
CLUE 2: What is the path to the Python executable?
(See also this question).
>>> import sys
>>> print sys.executable
Try this in the shell and in an IDLE script. If the two results are different, then you are using two Python interpreters and only one of them has a path that points to the wikipedia module.
CLUE 3: What is the sys.path?
Also repeat this in both shell and as a script in IDLE.
>>> print '\n'.join( sys.path )
(You may be able to use sys.path.append("d:/irectory/folder/is/in") to add that location to the sys.path. This should add that directory to the list of places Python looks for modules.)
CLUE 4: What is the PYTHONPATH and does it differ in the two environments?
(See also this answer).
Finally repeat this in both shell and as a script in IDLE.
>>> import os
>>> print '\n'.join( os.environ['PATH'].split(os.pathsep) )
Again note the two results (from shell and from IDLE) and see if there is difference in the PYTHONPATH in the two environments.
If all these tests prove inconclusive, I would add as much of this information as you can to your question as it would help give you specific further leads. Also add what OS you are using and any tracebacks that you get.
I had the same problem when trying to import a newly installed library on my Raspberry Pi. I followed all the instructions to install the library (Adafruit RHT Sensor) and it worked fine from the terminal. However, I couldn't get it to work from within IDLE.
It turned out that the problem was that the Raspberry Pi has both Python 2 and 3 installed. The install I'd done (using the 'python' command) only applied to Python 2. I had to perform another install using the 'python3' command to install it for Python 3. After that, I restarted IDLE and all worked fine.
The suggestion above to print the sys executable path helped point out the discrepancy:
import sys
print sys.executable
I have installed Python 2.6.7 in $HOME/local of a machine which already has a default Python in /usr (I don't have admin access on this machine). The default Python is compiled in 32bits and my local installation is a 64bits. For some unknown reasons my local Python library (which I call as an embedded python interpreter from within a C program) search for the modules in the default (wrong) installation.
This is the result of "import random"
Traceback (most recent call last):
File "test.py", line 3, in <module>
import random
File "/tmp/work/mdorier1/local/lib/python2.6/random.py", line 45, in <module>
from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil
ImportError: /usr/lib/python2.6/lib-dynload/math.so: wrong ELF class: ELFCLASS32
As you can see, the import statement correctly search "random.py" in the local installation of Python, but the import statement in random.py go search for math.so in the wrong location, which ends in an error since the default location has 32 bits modules.
I guessed there is a problem with an environment variable, and I tried
import sys
sys.path
to get
['/tmp/work/mdorier1/local/lib/python26.zip',
'/tmp/work/mdorier1/local/lib/python2.6',
'/tmp/work/mdorier1/local/lib/python2.6/plat-linux2',
'/tmp/work/mdorier1/local/lib/python2.6/lib-tk',
'/tmp/work/mdorier1/local/lib/python2.6/lib-old',
'/usr/lib/python2.6/lib-dynload',
'/tmp/work/mdorier1/local/lib/python2.6/site-packages']
I noticed that on of the paths indeed points to the default installation of Python. My questions thus are:
- Why this path shows up here, as the local installation has nothing to do with the default one?
- How do I change it (in a clean and permanent way)? This path should be the path to lib-dynload in the local installation instead.
Thanks
You probably don't have your Python's bin directory in the PATH variable before the system Python.
Or perhaps you simply compiled your Python incorrectly and did not use:
./configure --prefix=/tmp/work/mdorier1/local
so now it thinks that its files are somewhere else.