(go to: table of contents, index, prev: patches, next: programming guidelines)
The original version of GETPATH.C uses the path to the executable for further
lookup. This code has been removed from VMS__GETPATH.C. Several attempts are
made to find special 'landmark' files ("string.py") - this code as been
removed, too.
Two directories are needed:
A symbol or logical name "PYTHON_LIBRARY" is checked for the prefix.
Python's 'sys' module will contain a string named 'prefix'. Its value
will also be appended to the 'path' as shown below.
Note: the file specification must be in POSIX notation as shown below.
(Currently,) you cannot specify a list of file specifications (e.g.:
"/spec1:/spec2").
A symbol or logical name "PYTHON_SHARE" is checked for the exec_prefix.
Python's 'sys' module will contain a string named 'exec_prefix'. Its value
is currently (21-AUG-1999) NOT appended to 'sys.path'.
The POSIX environment still uses the Python-supplied routine in
[.PARSER]MYREADLINE.C
'Dynamic loading: adding object code to the text segment of a running process,
with the purpose -- usually -- of executing instructions from it' ...
On OpenVMS it is not possible to load object code this way. One might, instead,
put a module in a shareable image. The interpreter, however is not linked
against it, so it is not loaded at startup. The shareable image is only
activated when the module is being imported.
17-NOV-1999
I don't believe that makes much sense unless the module is _very_ big and not
used often. The minimum page size of an Alpha processor is at least 8 KBytes
and I think you would need at least several pages if you map a shareable image
via LIB$FIND_IMAGE_SYMBOL()
Note: module 'vms_lib' provides an
interface to LIB$FIND_IMAGE_SYMBOL()
to look up a symbol value in a shareable image, but there is currently
(17-NOV-1999) no way to call a routine in this image.
The idea was to put all routines in a shareable image to save space if
multiple variants were build. As mentioned above, some experiments have been
done, but it's not ready for release.
There is nothing in the implementation that tries to prevent embedding.
With version 1.5.2-V005 a simple demo has been created - see the
'embedding the Python interpreter'
path support
Python uses several 'environment variables' which tell the executable where
the other files (so called libraries) are located.
$ define PYTHON_LIBRARY "/DKA100/PYTHON/PYTHON-1_5_2/LIB"
$ python
Python 1.5.2 (V005a, Sat Aug 21 15:21:10 1999) [DECC] on vms
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
portions Copyright 1996-1999 Uwe Zessin
>>> print sys.prefix
/DKA100/PYTHON/PYTHON-1_5_2/LIB
>>>
@@ explain PYTHONPATH ...
command line editing
Note: this means that the shareable image SMGSHR.EXE is always linked to the
interpreter, even if the 'vms_smg' module
is not configured.
dynamic loading
On a Unix operation system this means, quoted from:
ftp://ftp.cwi.nl/pub/dynload/dl.txt
Some work has been done, but it did not made it into version 1.5.2-V006.
embedding Python on OpenVMS
Some comments in an earlier version of this manual raised some confusion.