Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.mrao.cam.ac.uk/~bn204/alma/sweng/pythonnotes.html
Дата изменения: Mon Apr 4 13:47:51 2016 Дата индексирования: Sun Apr 10 09:48:04 2016 Кодировка: ISO8859-5 Поисковые слова: aurora |
Both of these are search-paths, i.e., a list of paths (separated by the colon character) which are searched in sequence for a file containing a program with specific name. The Python path is used when searching for Python modules, i.e., programs written in Python and dynamic libraries that can be loaded into Python. However if you want to execute a program as a sub-processes, it will be searched for in the standard path, not the Python path.
You can see these paths as follows:
import sys
# This is the Python path
sys.path
import os
# This is the normal, system, path
os.environ["PATH"]
The Python path is initialised based on the PYTHONPATH environment variable and some standard system directories. The normal, system, path is based on the PATH environment variable.
All this can be relevant to ALMA data reduction process because the
WVR phase calibration program is an external command line program. If
you want to call it from Python, it will be searched for in the
os.environ["PATH"]
and not in the sys.path
list.
There are two options for telling Python where to look for the
wvrgcal
program:
You can adjust the PATH environment variable before starting Python or CASA:
PATH=$PATH:/users/bnikolic/p/wvr-0-15-1/bin/ casapy
This way of calling casapy adjusts the environment variable and executes casapy in one go
Adjust the system PATH after starting casapy:
os.environ["PATH"]+=":/users/bnikolic/p/wvr-0-15-1/bin/"
If you use absolute paths in your scripts (e.g.,
/users/bnikolic/test.dat
) then almost certainly the script will
not be runnable by others without some modification.
It is usually better to use paths relative to the current directory
(e.g., test.dat
, or anything else that does not start with /
)
or, relative to the user home directory:
os.path.join(os.environ["HOME"], "test.dat")
Functions should be documented using the doc string facility rather than the code comments. In other words:
defun testfn(p1, p2):
"""
A test function
"""
Is preferable to:
defun testfn(p1, p2):
# A test function
The reason for this is that the correct form is correctly parsed by
Python, and the user can retrieve the documentation by typing
help(testfn)
without looking at the source code.
getattr
functionТЖThe getattr
function is very useful in some situation. Here is the
help string:
>>> help(getattr)
Help on built-in function getattr in module __builtin__:
getattr(...)
getattr(object, name[, default]) -> value
Get a named attribute from an object; getattr(x, 'y') is equivalent to x.y.
When a default argument is given, it is returned when the attribute doesn't
exist; without it, an exception is raised in that case.
What it allows you to do is get a member (“attribute”) of an object with a name to be determined at run-time. So, instead of:
exec 'j=ephem.%s()' %src
One can do:
j=getattr(ephem, src)
Why is this so much better? Imagine for example that src
is
“J1000+100” – if you use the exec
approach it will be
misinterpreted as a an addition operation!
import
‘s within functionsТЖIn most situations it is best to import all of the required modules at the beginning of the script or module and not in individual functions. In this way missing modules will be detected at the time the script/module is parsed and not only after a (possibly computationally expensive) has been run.