I was reading this article about the sys module in python
And I came across this line:
The sys module in Python provides various functions and variables that are used to manipulate different parts of the Python runtime environment. It allows operating on the interpreter as it provides access to the variables and functions that interact strongly with the interpreter.
Can someone explain what this means? I don't get it
The Python runtime environment is the program that runs your python-scripts.
This program is called 'python' or 'python.exe'
Making a python-program means: Making a script (eg: MyScript.py) that can be fed in the python.exe program.
from the command prompt: python.exe MyScript.py
The sys module can be used in debugging (large) python-scripts.
Good Luck!
Related
I have installed Eclipse IDE with Python, I'm trying to setup an environment for writing some python scripts to automate Libre Office, I have made a script with just one line of code for now ("import libpyuno"), when i run this line of code i get an error:
ImportError: dynamic module does not define init function (initlibpyuno)
I have added "usr/lib/libreoffice/program" as external library path.
Can anyone tell me why I'm getting this error?
The supported way of using pyuno is to invoke the python interpreter bundled with LibreOffice itself. If you want to use an existing interpreter, then you need to make sure you manually do the same setup as the python shell script does inside the LibreOffice installation set (/usr/lib/libreoffice) in your case. This involves not only setting PYTHONPATH but at least specifying URE_BOOTSTRAP as well (both are environment variables.)
Now to your actual question: you probably don't want to import libpyuno. If you want to import a single LibreOffice-specific Python module for testing, then import just uno.
See https://cgit.freedesktop.org/libreoffice/core/tree/scripting/examples/python/NamedRanges.py for a real-world pyuno script, you can see even that only needs the uno module.
I recently had a problem with importing a python and therefore posted this question: Cant seem to import specific module in Python
Based on input I got I did some digging and saw the following:
If I open cygwin and input python --version, I get this
Marc#Marc ~
$ python --version
Python 2.7.12 :: Anaconda 4.2.0 (64-bit)
And if I open python using myCharm and input this:
import sys
print('\n'.join(sys.path))
I get:
C:\Users\Marc\Anaconda3\python.exe C:/Users/Marc/PycharmProjects/clustering/testing.py
C:\Users\Marc\PycharmProjects\clustering
C:\Users\Marc\PycharmProjects\clustering
C:\Users\Marc\Anaconda3\python35.zip
C:\Users\Marc\Anaconda3\DLLs
C:\Users\Marc\Anaconda3\lib
C:\Users\Marc\Anaconda3
C:\Users\Marc\Anaconda3\lib\site-packages
C:\Users\Marc\Anaconda3\lib\site-packages\Sphinx-1.4.6-py3.5.egg
C:\Users\Marc\Anaconda3\lib\site-packages\win32
C:\Users\Marc\Anaconda3\lib\site-packages\win32\lib
C:\Users\Marc\Anaconda3\lib\site-packages\Pythonwin
C:\Users\Marc\Anaconda3\lib\site-packages\setuptools-27.2.0-py3.5.egg
So assume this highlights the problem. Could anybody tell me what is wise to do here? Change the path in my terminal of change the path in python
If you set an envirnment variable called PYTHONPATH to a colon-separated (Windows: semicolon-separated) list of directories, each of them will be added to the interpreter's sys.path. This is the recommended way of making modules available.
So for example, let's suppose you had added Python modules in the directory C:\Documents and Settings\frits\private. Before you run your Python program you would execute the command
SET PYTHONPATH=C:\Documents and Settings\frits\private
No semicolon is required in this case because there's only one directory.
The when you run Python you will find that your sys.path has another entry corresponding to the C:\Documents and Settings\frits\private directory.
In the longer term, to avoid conflicts between the requirements of different projects (e.g. you want to run two programs that require a different version of the same third-party module) you should investigate the use of virtual environments.
I was trying to write a python script and execute it within blender context. But it reports 'Import Error : No module named "bpy"'. I tried installing another version of blender ( viz. 2.7.6 ) but as it appears there is actually no module named bpy inside "blender-2.76-rc2-win64\2.76\python\lib" , which is the path where python is searching for modules I suppose. I checked out the docs for blender but there is no explicit way of downloading bpy. Any help will be appreciated.
The bpy module is a built-in part of blender that gives python scripts access to the data and operators used in blender. This module is available to scripts run within blender itself, which includes a python interpreter. The bpy module isn't normally available to import from a normal python command, but there is limited support to compile a blender module.
To use the bpy module you can start blender and use the built in python console or you can type in or open a script in the text editor which has a run script button available. Particularly if you run scripts from the text editor you will want access to a console to get error reports.
I have a problem which is caused by our encapsulated design. Up till now lots of our scripts were written in bash and as a result the #!/bin/bash was always simple.
However now that we are rewriting our scripts in python that is a bit more difficult. We deliver a specific version of python (to avoid version differences in client installed environments from breaking our implementation). Because the specific version of python lives in a installed directory structure I need to route to it.
However I don't think the #! statement can accept environment variables from the shell that executes the file(tried and got a bad interpreter).
eg:
in foo.py I have #!$dirloc/wherepythonlives/python
In the bash shell I executed the file and got bad interpreter.
Is there a way of sneaking an environment variable into that #! line?
Or will I have to depend on an explicit path? We want to support multiple versions of our software (which may mean multiple python versions) on one environment so I was hoping to somehow keep Python's !# statement inside the directory level we install into.
A common way to do this is to use the env program:
#!/usr/bin/env python
This will cause env to look along the PATH environment for a binary called python.
I'm not aware of being able to use environment variable in the shebang. You can use relative paths though
#! ../../usr/bin/python
edit:
You could always use env to specify to use a specific version. Then if that version can be found in $PATH it will be used otherwise the script will fail
#! /usr/bin/env python2.7
Or you could make the entry point a generic script instead.
eg
#! /usr/bin/env bash
if [[ $MYPYTHON ]]
then
$MYPYTHON main.py
else
echo error message
fi
The optimal solution to this dilemma is using distutils (setup.py, which creates correct stubs for you automatically, for a number of given "console entry points") and virtualenv (handling the "isolated multiple installations" part).
I suppose it all depends on how and in what environment your scripts will be invoked. You could call you scripts using #!/usr/bin/env python, which would allow you to control which python is used by manipulating the environment's PATH.
You could always specify a wrapper script as the interpreter, which runs a python executable relative to the script's location:
foo.py:
#!/bin/pyselector
import sys
sys.exit(0)
pyselector:
#!/bin/sh
SCRIPT_PATH="$(readlink -f $1)"
SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
"${SCRIPT_DIR}/my/local/python" "$#"
One of my Python scripts runs in interactive mode but fails when run from the command line. The difference is that when run from the command line, it imports modules from a bad .egg file, and when run interactively it uses my fixed (unzipped) version in the current directory.
My question is two-fold: a) why does Python load modules differently when run from these locations, and b) what are my options to work around it?
I don't understand what do you mean by running script in interactive mode, so I can't say exactly. But the first place to look for modules (sys.path[0]) in interactive mode is current directory (even calling os.chdir() will affect imports), while for script it's directory where the script is located (derived from sys.argv[0]). Note that they are effectively the same when script is run from directory where it's located, but could be different in other cases. Hope this helps.
On UNIX systems and Mac OS-X:
Do you have a ~/.python-eggs directory?
OS independent:
Are you sure that you use the same Python instance in both cases?
Can you print sys.path in each cases and see which package directory comes first on your module search path?
a) why does Python load modules differently when run from these locations
b) what are my options to work around it?
Check your environment variable PYTHONPATH. When python imports module, it searches those directories. One way to get around your problem is to add your local folder "the (unzipped) version in the current directory" to the beginning of PYTHONPATH so that python will find it first.
This works for me:
import sys
sys.path[0]=''