Fred Drake | 3adf79e | 2001-10-12 19:01:43 +0000 | [diff] [blame] | 1 | \chapter{Utilities \label{utilities}} |
| 2 | |
| 3 | The functions in this chapter perform various utility tasks, ranging |
| 4 | from helping C code be more portable across platforms, using Python |
| 5 | modules from C, and parsing function arguments and constructing Python |
| 6 | values from C values. |
| 7 | |
| 8 | |
| 9 | \section{Operating System Utilities \label{os}} |
| 10 | |
| 11 | \begin{cfuncdesc}{int}{Py_FdIsInteractive}{FILE *fp, char *filename} |
| 12 | Return true (nonzero) if the standard I/O file \var{fp} with name |
| 13 | \var{filename} is deemed interactive. This is the case for files |
| 14 | for which \samp{isatty(fileno(\var{fp}))} is true. If the global |
| 15 | flag \cdata{Py_InteractiveFlag} is true, this function also returns |
| 16 | true if the \var{filename} pointer is \NULL{} or if the name is |
| 17 | equal to one of the strings \code{'<stdin>'} or \code{'???'}. |
| 18 | \end{cfuncdesc} |
| 19 | |
| 20 | \begin{cfuncdesc}{long}{PyOS_GetLastModificationTime}{char *filename} |
| 21 | Return the time of last modification of the file \var{filename}. |
| 22 | The result is encoded in the same way as the timestamp returned by |
| 23 | the standard C library function \cfunction{time()}. |
| 24 | \end{cfuncdesc} |
| 25 | |
| 26 | \begin{cfuncdesc}{void}{PyOS_AfterFork}{} |
| 27 | Function to update some internal state after a process fork; this |
| 28 | should be called in the new process if the Python interpreter will |
| 29 | continue to be used. If a new executable is loaded into the new |
| 30 | process, this function does not need to be called. |
| 31 | \end{cfuncdesc} |
| 32 | |
| 33 | \begin{cfuncdesc}{int}{PyOS_CheckStack}{} |
| 34 | Return true when the interpreter runs out of stack space. This is a |
| 35 | reliable check, but is only available when \constant{USE_STACKCHECK} |
| 36 | is defined (currently on Windows using the Microsoft Visual \Cpp{} |
| 37 | compiler and on the Macintosh). \constant{USE_CHECKSTACK} will be |
| 38 | defined automatically; you should never change the definition in |
| 39 | your own code. |
| 40 | \end{cfuncdesc} |
| 41 | |
| 42 | \begin{cfuncdesc}{PyOS_sighandler_t}{PyOS_getsig}{int i} |
| 43 | Return the current signal handler for signal \var{i}. This is a |
| 44 | thin wrapper around either \cfunction{sigaction()} or |
| 45 | \cfunction{signal()}. Do not call those functions directly! |
| 46 | \ctype{PyOS_sighandler_t} is a typedef alias for \ctype{void |
| 47 | (*)(int)}. |
| 48 | \end{cfuncdesc} |
| 49 | |
| 50 | \begin{cfuncdesc}{PyOS_sighandler_t}{PyOS_setsig}{int i, PyOS_sighandler_t h} |
| 51 | Set the signal handler for signal \var{i} to be \var{h}; return the |
| 52 | old signal handler. This is a thin wrapper around either |
| 53 | \cfunction{sigaction()} or \cfunction{signal()}. Do not call those |
| 54 | functions directly! \ctype{PyOS_sighandler_t} is a typedef alias |
| 55 | for \ctype{void (*)(int)}. |
| 56 | \end{cfuncdesc} |
| 57 | |
| 58 | |
| 59 | \section{Process Control \label{processControl}} |
| 60 | |
| 61 | \begin{cfuncdesc}{void}{Py_FatalError}{char *message} |
| 62 | Print a fatal error message and kill the process. No cleanup is |
| 63 | performed. This function should only be invoked when a condition is |
| 64 | detected that would make it dangerous to continue using the Python |
| 65 | interpreter; e.g., when the object administration appears to be |
| 66 | corrupted. On \UNIX, the standard C library function |
| 67 | \cfunction{abort()}\ttindex{abort()} is called which will attempt to |
| 68 | produce a \file{core} file. |
| 69 | \end{cfuncdesc} |
| 70 | |
| 71 | \begin{cfuncdesc}{void}{Py_Exit}{int status} |
| 72 | Exit the current process. This calls |
| 73 | \cfunction{Py_Finalize()}\ttindex{Py_Finalize()} and then calls the |
| 74 | standard C library function |
| 75 | \code{exit(\var{status})}\ttindex{exit()}. |
| 76 | \end{cfuncdesc} |
| 77 | |
| 78 | \begin{cfuncdesc}{int}{Py_AtExit}{void (*func) ()} |
| 79 | Register a cleanup function to be called by |
| 80 | \cfunction{Py_Finalize()}\ttindex{Py_Finalize()}. The cleanup |
| 81 | function will be called with no arguments and should return no |
| 82 | value. At most 32 \index{cleanup functions}cleanup functions can be |
| 83 | registered. When the registration is successful, |
| 84 | \cfunction{Py_AtExit()} returns \code{0}; on failure, it returns |
| 85 | \code{-1}. The cleanup function registered last is called first. |
| 86 | Each cleanup function will be called at most once. Since Python's |
| 87 | internal finallization will have completed before the cleanup |
| 88 | function, no Python APIs should be called by \var{func}. |
| 89 | \end{cfuncdesc} |
| 90 | |
| 91 | |
| 92 | \section{Importing Modules \label{importing}} |
| 93 | |
| 94 | \begin{cfuncdesc}{PyObject*}{PyImport_ImportModule}{char *name} |
| 95 | This is a simplified interface to |
| 96 | \cfunction{PyImport_ImportModuleEx()} below, leaving the |
| 97 | \var{globals} and \var{locals} arguments set to \NULL. When the |
| 98 | \var{name} argument contains a dot (when it specifies a submodule of |
| 99 | a package), the \var{fromlist} argument is set to the list |
| 100 | \code{['*']} so that the return value is the named module rather |
| 101 | than the top-level package containing it as would otherwise be the |
| 102 | case. (Unfortunately, this has an additional side effect when |
| 103 | \var{name} in fact specifies a subpackage instead of a submodule: |
| 104 | the submodules specified in the package's \code{__all__} variable |
| 105 | are \index{package variable!\code{__all__}} |
| 106 | \withsubitem{(package variable)}{\ttindex{__all__}}loaded.) Return |
| 107 | a new reference to the imported module, or \NULL{} with an exception |
| 108 | set on failure (the module may still be created in this case --- |
| 109 | examine \code{sys.modules} to find out). |
| 110 | \withsubitem{(in module sys)}{\ttindex{modules}} |
| 111 | \end{cfuncdesc} |
| 112 | |
| 113 | \begin{cfuncdesc}{PyObject*}{PyImport_ImportModuleEx}{char *name, |
| 114 | PyObject *globals, PyObject *locals, PyObject *fromlist} |
| 115 | Import a module. This is best described by referring to the |
| 116 | built-in Python function |
| 117 | \function{__import__()}\bifuncindex{__import__}, as the standard |
| 118 | \function{__import__()} function calls this function directly. |
| 119 | |
| 120 | The return value is a new reference to the imported module or |
| 121 | top-level package, or \NULL{} with an exception set on failure (the |
| 122 | module may still be created in this case). Like for |
| 123 | \function{__import__()}, the return value when a submodule of a |
| 124 | package was requested is normally the top-level package, unless a |
| 125 | non-empty \var{fromlist} was given. |
| 126 | \end{cfuncdesc} |
| 127 | |
| 128 | \begin{cfuncdesc}{PyObject*}{PyImport_Import}{PyObject *name} |
| 129 | This is a higher-level interface that calls the current ``import |
| 130 | hook function''. It invokes the \function{__import__()} function |
| 131 | from the \code{__builtins__} of the current globals. This means |
| 132 | that the import is done using whatever import hooks are installed in |
| 133 | the current environment, e.g. by \module{rexec}\refstmodindex{rexec} |
| 134 | or \module{ihooks}\refstmodindex{ihooks}. |
| 135 | \end{cfuncdesc} |
| 136 | |
| 137 | \begin{cfuncdesc}{PyObject*}{PyImport_ReloadModule}{PyObject *m} |
| 138 | Reload a module. This is best described by referring to the |
| 139 | built-in Python function \function{reload()}\bifuncindex{reload}, as |
| 140 | the standard \function{reload()} function calls this function |
| 141 | directly. Return a new reference to the reloaded module, or \NULL{} |
| 142 | with an exception set on failure (the module still exists in this |
| 143 | case). |
| 144 | \end{cfuncdesc} |
| 145 | |
| 146 | \begin{cfuncdesc}{PyObject*}{PyImport_AddModule}{char *name} |
| 147 | Return the module object corresponding to a module name. The |
| 148 | \var{name} argument may be of the form \code{package.module}). |
| 149 | First check the modules dictionary if there's one there, and if not, |
| 150 | create a new one and insert in in the modules dictionary. |
| 151 | \note{This function does not load or import the module; if the |
| 152 | module wasn't already loaded, you will get an empty module object. |
| 153 | Use \cfunction{PyImport_ImportModule()} or one of its variants to |
| 154 | import a module. Return \NULL{} with an exception set on failure.} |
| 155 | \end{cfuncdesc} |
| 156 | |
| 157 | \begin{cfuncdesc}{PyObject*}{PyImport_ExecCodeModule}{char *name, PyObject *co} |
| 158 | Given a module name (possibly of the form \code{package.module}) and |
| 159 | a code object read from a Python bytecode file or obtained from the |
| 160 | built-in function \function{compile()}\bifuncindex{compile}, load |
| 161 | the module. Return a new reference to the module object, or \NULL{} |
| 162 | with an exception set if an error occurred (the module may still be |
| 163 | created in this case). (This function would reload the module if it |
| 164 | was already imported.) |
| 165 | \end{cfuncdesc} |
| 166 | |
| 167 | \begin{cfuncdesc}{long}{PyImport_GetMagicNumber}{} |
| 168 | Return the magic number for Python bytecode files |
| 169 | (a.k.a. \file{.pyc} and \file{.pyo} files). The magic number should |
| 170 | be present in the first four bytes of the bytecode file, in |
| 171 | little-endian byte order. |
| 172 | \end{cfuncdesc} |
| 173 | |
| 174 | \begin{cfuncdesc}{PyObject*}{PyImport_GetModuleDict}{} |
| 175 | Return the dictionary used for the module administration |
| 176 | (a.k.a.\ \code{sys.modules}). Note that this is a per-interpreter |
| 177 | variable. |
| 178 | \end{cfuncdesc} |
| 179 | |
| 180 | \begin{cfuncdesc}{void}{_PyImport_Init}{} |
| 181 | Initialize the import mechanism. For internal use only. |
| 182 | \end{cfuncdesc} |
| 183 | |
| 184 | \begin{cfuncdesc}{void}{PyImport_Cleanup}{} |
| 185 | Empty the module table. For internal use only. |
| 186 | \end{cfuncdesc} |
| 187 | |
| 188 | \begin{cfuncdesc}{void}{_PyImport_Fini}{} |
| 189 | Finalize the import mechanism. For internal use only. |
| 190 | \end{cfuncdesc} |
| 191 | |
| 192 | \begin{cfuncdesc}{PyObject*}{_PyImport_FindExtension}{char *, char *} |
| 193 | For internal use only. |
| 194 | \end{cfuncdesc} |
| 195 | |
| 196 | \begin{cfuncdesc}{PyObject*}{_PyImport_FixupExtension}{char *, char *} |
| 197 | For internal use only. |
| 198 | \end{cfuncdesc} |
| 199 | |
| 200 | \begin{cfuncdesc}{int}{PyImport_ImportFrozenModule}{char *name} |
| 201 | Load a frozen module named \var{name}. Return \code{1} for success, |
| 202 | \code{0} if the module is not found, and \code{-1} with an exception |
| 203 | set if the initialization failed. To access the imported module on |
| 204 | a successful load, use \cfunction{PyImport_ImportModule()}. (Note |
| 205 | the misnomer --- this function would reload the module if it was |
| 206 | already imported.) |
| 207 | \end{cfuncdesc} |
| 208 | |
| 209 | \begin{ctypedesc}[_frozen]{struct _frozen} |
| 210 | This is the structure type definition for frozen module descriptors, |
| 211 | as generated by the \program{freeze}\index{freeze utility} utility |
| 212 | (see \file{Tools/freeze/} in the Python source distribution). Its |
| 213 | definition, found in \file{Include/import.h}, is: |
| 214 | |
| 215 | \begin{verbatim} |
| 216 | struct _frozen { |
| 217 | char *name; |
| 218 | unsigned char *code; |
| 219 | int size; |
| 220 | }; |
| 221 | \end{verbatim} |
| 222 | \end{ctypedesc} |
| 223 | |
| 224 | \begin{cvardesc}{struct _frozen*}{PyImport_FrozenModules} |
| 225 | This pointer is initialized to point to an array of \ctype{struct |
| 226 | _frozen} records, terminated by one whose members are all \NULL{} or |
| 227 | zero. When a frozen module is imported, it is searched in this |
| 228 | table. Third-party code could play tricks with this to provide a |
| 229 | dynamically created collection of frozen modules. |
| 230 | \end{cvardesc} |
| 231 | |
| 232 | \begin{cfuncdesc}{int}{PyImport_AppendInittab}{char *name, |
| 233 | void (*initfunc)(void)} |
| 234 | Add a single module to the existing table of built-in modules. This |
| 235 | is a convenience wrapper around |
| 236 | \cfunction{PyImport_ExtendInittab()}, returning \code{-1} if the |
| 237 | table could not be extended. The new module can be imported by the |
| 238 | name \var{name}, and uses the function \var{initfunc} as the |
| 239 | initialization function called on the first attempted import. This |
| 240 | should be called before \cfunction{Py_Initialize()}. |
| 241 | \end{cfuncdesc} |
| 242 | |
| 243 | \begin{ctypedesc}[_inittab]{struct _inittab} |
| 244 | Structure describing a single entry in the list of built-in |
| 245 | modules. Each of these structures gives the name and initialization |
| 246 | function for a module built into the interpreter. Programs which |
| 247 | embed Python may use an array of these structures in conjunction |
| 248 | with \cfunction{PyImport_ExtendInittab()} to provide additional |
| 249 | built-in modules. The structure is defined in |
| 250 | \file{Include/import.h} as: |
| 251 | |
| 252 | \begin{verbatim} |
| 253 | struct _inittab { |
| 254 | char *name; |
| 255 | void (*initfunc)(void); |
| 256 | }; |
| 257 | \end{verbatim} |
| 258 | \end{ctypedesc} |
| 259 | |
| 260 | \begin{cfuncdesc}{int}{PyImport_ExtendInittab}{struct _inittab *newtab} |
| 261 | Add a collection of modules to the table of built-in modules. The |
| 262 | \var{newtab} array must end with a sentinel entry which contains |
| 263 | \NULL{} for the \member{name} field; failure to provide the sentinel |
| 264 | value can result in a memory fault. Returns \code{0} on success or |
| 265 | \code{-1} if insufficient memory could be allocated to extend the |
| 266 | internal table. In the event of failure, no modules are added to |
| 267 | the internal table. This should be called before |
| 268 | \cfunction{Py_Initialize()}. |
| 269 | \end{cfuncdesc} |
| 270 | |
| 271 | |
Fred Drake | 0fae49f | 2001-10-14 04:45:51 +0000 | [diff] [blame] | 272 | \section{Data marshalling support \label{marshalling-utils}} |
| 273 | |
| 274 | These routines allow C code to work with serialized objects using the |
| 275 | same data format as the \module{marshal} module. There are functions |
| 276 | to write data into the serialization format, and additional functions |
| 277 | that can be used to read the data back. Files used to store marshalled |
| 278 | data must be opened in binary mode. |
| 279 | |
| 280 | Numeric values are stored with the least significant byte first. |
| 281 | |
| 282 | \begin{cfuncdesc}{void}{PyMarshal_WriteLongToFile}{long value, FILE *file} |
| 283 | Marshal a \ctype{long} integer, \var{value}, to \var{file}. This |
| 284 | will only write the least-significant 32 bits of \var{value}; |
| 285 | regardless of the size of the native \ctype{long} type. |
| 286 | \end{cfuncdesc} |
| 287 | |
| 288 | \begin{cfuncdesc}{void}{PyMarshal_WriteShortToFile}{short value, FILE *file} |
| 289 | Marshal a \ctype{short} integer, \var{value}, to \var{file}. |
| 290 | \end{cfuncdesc} |
| 291 | |
| 292 | \begin{cfuncdesc}{void}{PyMarshal_WriteObjectToFile}{PyObject *value, |
| 293 | FILE *file} |
| 294 | Marshal a Python object, \var{value}, to \var{file}. This |
| 295 | will only write the least-significant 16 bits of \var{value}; |
| 296 | regardless of the size of the native \ctype{short} type. |
| 297 | \end{cfuncdesc} |
| 298 | |
| 299 | \begin{cfuncdesc}{PyObject*}{PyMarshal_WriteObjectToString}{PyObject *value} |
| 300 | Return a string object containing the marshalled representation of |
| 301 | \var{value}. |
| 302 | \end{cfuncdesc} |
| 303 | |
| 304 | The following functions allow marshalled values to be read back in. |
| 305 | |
| 306 | XXX What about error detection? It appears that reading past the end |
| 307 | of the file will always result in a negative numeric value (where |
| 308 | that's relevant), but it's not clear that negative values won't be |
| 309 | handled properly when there's no error. What's the right way to tell? |
| 310 | Should only non-negative values be written using these routines? |
| 311 | |
| 312 | \begin{cfuncdesc}{long}{PyMarshal_ReadLongFromFile}{FILE *file} |
| 313 | Return a C \ctype{long} from the data stream in a \ctype{FILE*} |
| 314 | opened for reading. Only a 32-bit value can be read in using |
| 315 | this function, regardless of the native size of \ctype{long}. |
| 316 | \end{cfuncdesc} |
| 317 | |
| 318 | \begin{cfuncdesc}{int}{PyMarshal_ReadShortFromFile}{FILE *file} |
| 319 | Return a C \ctype{short} from the data stream in a \ctype{FILE*} |
| 320 | opened for reading. Only a 16-bit value can be read in using |
| 321 | this function, regardless of the native size of \ctype{long}. |
| 322 | \end{cfuncdesc} |
| 323 | |
| 324 | \begin{cfuncdesc}{PyObject*}{PyMarshal_ReadObjectFromFile}{FILE *file} |
| 325 | Return a Python object from the data stream in a \ctype{FILE*} |
| 326 | opened for reading. On error, sets the appropriate exception |
| 327 | (\exception{EOFError} or \exception{TypeError}) and returns \NULL. |
| 328 | \end{cfuncdesc} |
| 329 | |
| 330 | \begin{cfuncdesc}{PyObject*}{PyMarshal_ReadLastObjectFromFile}{FILE *file} |
| 331 | Return a Python object from the data stream in a \ctype{FILE*} |
| 332 | opened for reading. Unlike |
| 333 | \cfunction{PyMarshal_ReadObjectFromFile()}, this function assumes |
| 334 | that no further objects will be read from the file, allowing it to |
| 335 | aggressively load file data into memory so that the de-serialization |
| 336 | can operate from data in memory rather than reading a byte at a time |
| 337 | from the file. Only use these variant if you are certain that you |
| 338 | won't be reading anything else from the file. On error, sets the |
| 339 | appropriate exception (\exception{EOFError} or |
| 340 | \exception{TypeError}) and returns \NULL. |
| 341 | \end{cfuncdesc} |
| 342 | |
| 343 | \begin{cfuncdesc}{PyObject*}{PyMarshal_ReadObjectFromString}{char *string, |
| 344 | int len} |
| 345 | Return a Python object from the data stream in a character buffer |
| 346 | containing \var{len} bytes pointed to by \var{string}. On error, |
| 347 | sets the appropriate exception (\exception{EOFError} or |
| 348 | \exception{TypeError}) and returns \NULL. |
| 349 | \end{cfuncdesc} |
| 350 | |
| 351 | |
Fred Drake | 3adf79e | 2001-10-12 19:01:43 +0000 | [diff] [blame] | 352 | \section{Parsing arguments and building values |
| 353 | \label{arg-parsing}} |
| 354 | |
| 355 | These functions are useful when creating your own extensions functions |
| 356 | and methods. Additional information and examples are available in |
| 357 | \citetitle[../ext/ext.html]{Extending and Embedding the Python |
| 358 | Interpreter}. |
| 359 | |
| 360 | \begin{cfuncdesc}{int}{PyArg_ParseTuple}{PyObject *args, char *format, |
| 361 | \moreargs} |
| 362 | Parse the parameters of a function that takes only positional |
| 363 | parameters into local variables. Returns true on success; on |
| 364 | failure, it returns false and raises the appropriate exception. See |
| 365 | \citetitle[../ext/parseTuple.html]{Extending and Embedding the |
| 366 | Python Interpreter} for more information. |
| 367 | \end{cfuncdesc} |
| 368 | |
| 369 | \begin{cfuncdesc}{int}{PyArg_ParseTupleAndKeywords}{PyObject *args, |
| 370 | PyObject *kw, char *format, char *keywords[], |
| 371 | \moreargs} |
| 372 | Parse the parameters of a function that takes both positional and |
| 373 | keyword parameters into local variables. Returns true on success; |
| 374 | on failure, it returns false and raises the appropriate exception. |
| 375 | See \citetitle[../ext/parseTupleAndKeywords.html]{Extending and |
| 376 | Embedding the Python Interpreter} for more information. |
| 377 | \end{cfuncdesc} |
| 378 | |
| 379 | \begin{cfuncdesc}{int}{PyArg_Parse}{PyObject *args, char *format, |
| 380 | \moreargs} |
| 381 | Function used to deconstruct the argument lists of ``old-style'' |
| 382 | functions --- these are functions which use the |
| 383 | \constant{METH_OLDARGS} parameter parsing method. This is not |
| 384 | recommended for use in parameter parsing in new code, and most code |
| 385 | in the standard interpreter has been modified to no longer use this |
| 386 | for that purpose. It does remain a convenient way to decompose |
| 387 | other tuples, however, and may continue to be used for that |
| 388 | purpose. |
| 389 | \end{cfuncdesc} |
| 390 | |
| 391 | \begin{cfuncdesc}{PyObject*}{Py_BuildValue}{char *format, |
| 392 | \moreargs} |
| 393 | Create a new value based on a format string similar to those |
| 394 | accepted by the \cfunction{PyArg_Parse*()} family of functions and a |
| 395 | sequence of values. Returns the value or \NULL{} in the case of an |
| 396 | error; an exception will be raised if \NULL{} is returned. For more |
| 397 | information on the format string and additional parameters, see |
| 398 | \citetitle[../ext/buildValue.html]{Extending and Embedding the |
| 399 | Python Interpreter}. |
| 400 | \end{cfuncdesc} |