1 | \section{\module{sys} ---
|
---|
2 | System-specific parameters and functions}
|
---|
3 |
|
---|
4 | \declaremodule{builtin}{sys}
|
---|
5 | \modulesynopsis{Access system-specific parameters and functions.}
|
---|
6 |
|
---|
7 | This module provides access to some variables used or maintained by the
|
---|
8 | interpreter and to functions that interact strongly with the interpreter.
|
---|
9 | It is always available.
|
---|
10 |
|
---|
11 |
|
---|
12 | \begin{datadesc}{argv}
|
---|
13 | The list of command line arguments passed to a Python script.
|
---|
14 | \code{argv[0]} is the script name (it is operating system dependent
|
---|
15 | whether this is a full pathname or not). If the command was
|
---|
16 | executed using the \programopt{-c} command line option to the
|
---|
17 | interpreter, \code{argv[0]} is set to the string \code{'-c'}. If no
|
---|
18 | script name was passed to the Python interpreter, \code{argv} has
|
---|
19 | zero length.
|
---|
20 | \end{datadesc}
|
---|
21 |
|
---|
22 | \begin{datadesc}{byteorder}
|
---|
23 | An indicator of the native byte order. This will have the value
|
---|
24 | \code{'big'} on big-endian (most-significant byte first) platforms,
|
---|
25 | and \code{'little'} on little-endian (least-significant byte first)
|
---|
26 | platforms.
|
---|
27 | \versionadded{2.0}
|
---|
28 | \end{datadesc}
|
---|
29 |
|
---|
30 | \begin{datadesc}{subversion}
|
---|
31 | A triple (repo, branch, version) representing the Subversion
|
---|
32 | information of the Python interpreter.
|
---|
33 | \var{repo} is the name of the repository, \code{'CPython'}.
|
---|
34 | \var{branch} is a string of one of the forms \code{'trunk'},
|
---|
35 | \code{'branches/name'} or \code{'tags/name'}.
|
---|
36 | \var{version} is the output of \code{svnversion}, if the
|
---|
37 | interpreter was built from a Subversion checkout; it contains
|
---|
38 | the revision number (range) and possibly a trailing 'M' if
|
---|
39 | there were local modifications. If the tree was exported
|
---|
40 | (or svnversion was not available), it is the revision of
|
---|
41 | \code{Include/patchlevel.h} if the branch is a tag. Otherwise,
|
---|
42 | it is \code{None}.
|
---|
43 | \versionadded{2.5}
|
---|
44 | \end{datadesc}
|
---|
45 |
|
---|
46 | \begin{datadesc}{builtin_module_names}
|
---|
47 | A tuple of strings giving the names of all modules that are compiled
|
---|
48 | into this Python interpreter. (This information is not available in
|
---|
49 | any other way --- \code{modules.keys()} only lists the imported
|
---|
50 | modules.)
|
---|
51 | \end{datadesc}
|
---|
52 |
|
---|
53 | \begin{datadesc}{copyright}
|
---|
54 | A string containing the copyright pertaining to the Python
|
---|
55 | interpreter.
|
---|
56 | \end{datadesc}
|
---|
57 |
|
---|
58 | \begin{funcdesc}{_current_frames}{}
|
---|
59 | Return a dictionary mapping each thread's identifier to the topmost stack
|
---|
60 | frame currently active in that thread at the time the function is called.
|
---|
61 | Note that functions in the \refmodule{traceback} module can build the
|
---|
62 | call stack given such a frame.
|
---|
63 |
|
---|
64 | This is most useful for debugging deadlock: this function does not
|
---|
65 | require the deadlocked threads' cooperation, and such threads' call stacks
|
---|
66 | are frozen for as long as they remain deadlocked. The frame returned
|
---|
67 | for a non-deadlocked thread may bear no relationship to that thread's
|
---|
68 | current activity by the time calling code examines the frame.
|
---|
69 |
|
---|
70 | This function should be used for internal and specialized purposes
|
---|
71 | only.
|
---|
72 | \versionadded{2.5}
|
---|
73 | \end{funcdesc}
|
---|
74 |
|
---|
75 | \begin{datadesc}{dllhandle}
|
---|
76 | Integer specifying the handle of the Python DLL.
|
---|
77 | Availability: Windows.
|
---|
78 | \end{datadesc}
|
---|
79 |
|
---|
80 | \begin{funcdesc}{displayhook}{\var{value}}
|
---|
81 | If \var{value} is not \code{None}, this function prints it to
|
---|
82 | \code{sys.stdout}, and saves it in \code{__builtin__._}.
|
---|
83 |
|
---|
84 | \code{sys.displayhook} is called on the result of evaluating an
|
---|
85 | expression entered in an interactive Python session. The display of
|
---|
86 | these values can be customized by assigning another one-argument
|
---|
87 | function to \code{sys.displayhook}.
|
---|
88 | \end{funcdesc}
|
---|
89 |
|
---|
90 | \begin{funcdesc}{excepthook}{\var{type}, \var{value}, \var{traceback}}
|
---|
91 | This function prints out a given traceback and exception to
|
---|
92 | \code{sys.stderr}.
|
---|
93 |
|
---|
94 | When an exception is raised and uncaught, the interpreter calls
|
---|
95 | \code{sys.excepthook} with three arguments, the exception class,
|
---|
96 | exception instance, and a traceback object. In an interactive
|
---|
97 | session this happens just before control is returned to the prompt;
|
---|
98 | in a Python program this happens just before the program exits. The
|
---|
99 | handling of such top-level exceptions can be customized by assigning
|
---|
100 | another three-argument function to \code{sys.excepthook}.
|
---|
101 | \end{funcdesc}
|
---|
102 |
|
---|
103 | \begin{datadesc}{__displayhook__}
|
---|
104 | \dataline{__excepthook__}
|
---|
105 | These objects contain the original values of \code{displayhook} and
|
---|
106 | \code{excepthook} at the start of the program. They are saved so
|
---|
107 | that \code{displayhook} and \code{excepthook} can be restored in
|
---|
108 | case they happen to get replaced with broken objects.
|
---|
109 | \end{datadesc}
|
---|
110 |
|
---|
111 | \begin{funcdesc}{exc_info}{}
|
---|
112 | This function returns a tuple of three values that give information
|
---|
113 | about the exception that is currently being handled. The
|
---|
114 | information returned is specific both to the current thread and to
|
---|
115 | the current stack frame. If the current stack frame is not handling
|
---|
116 | an exception, the information is taken from the calling stack frame,
|
---|
117 | or its caller, and so on until a stack frame is found that is
|
---|
118 | handling an exception. Here, ``handling an exception'' is defined
|
---|
119 | as ``executing or having executed an except clause.'' For any stack
|
---|
120 | frame, only information about the most recently handled exception is
|
---|
121 | accessible.
|
---|
122 |
|
---|
123 | If no exception is being handled anywhere on the stack, a tuple
|
---|
124 | containing three \code{None} values is returned. Otherwise, the
|
---|
125 | values returned are \code{(\var{type}, \var{value},
|
---|
126 | \var{traceback})}. Their meaning is: \var{type} gets the exception
|
---|
127 | type of the exception being handled (a class object);
|
---|
128 | \var{value} gets the exception parameter (its \dfn{associated value}
|
---|
129 | or the second argument to \keyword{raise}, which is always a class
|
---|
130 | instance if the exception type is a class object); \var{traceback}
|
---|
131 | gets a traceback object (see the Reference Manual) which
|
---|
132 | encapsulates the call stack at the point where the exception
|
---|
133 | originally occurred. \obindex{traceback}
|
---|
134 |
|
---|
135 | If \function{exc_clear()} is called, this function will return three
|
---|
136 | \code{None} values until either another exception is raised in the
|
---|
137 | current thread or the execution stack returns to a frame where
|
---|
138 | another exception is being handled.
|
---|
139 |
|
---|
140 | \warning{Assigning the \var{traceback} return value to a
|
---|
141 | local variable in a function that is handling an exception will
|
---|
142 | cause a circular reference. This will prevent anything referenced
|
---|
143 | by a local variable in the same function or by the traceback from
|
---|
144 | being garbage collected. Since most functions don't need access to
|
---|
145 | the traceback, the best solution is to use something like
|
---|
146 | \code{exctype, value = sys.exc_info()[:2]} to extract only the
|
---|
147 | exception type and value. If you do need the traceback, make sure
|
---|
148 | to delete it after use (best done with a \keyword{try}
|
---|
149 | ... \keyword{finally} statement) or to call \function{exc_info()} in
|
---|
150 | a function that does not itself handle an exception.} \note{Beginning
|
---|
151 | with Python 2.2, such cycles are automatically reclaimed when garbage
|
---|
152 | collection is enabled and they become unreachable, but it remains more
|
---|
153 | efficient to avoid creating cycles.}
|
---|
154 | \end{funcdesc}
|
---|
155 |
|
---|
156 | \begin{funcdesc}{exc_clear}{}
|
---|
157 | This function clears all information relating to the current or last
|
---|
158 | exception that occurred in the current thread. After calling this
|
---|
159 | function, \function{exc_info()} will return three \code{None} values until
|
---|
160 | another exception is raised in the current thread or the execution stack
|
---|
161 | returns to a frame where another exception is being handled.
|
---|
162 |
|
---|
163 | This function is only needed in only a few obscure situations. These
|
---|
164 | include logging and error handling systems that report information on the
|
---|
165 | last or current exception. This function can also be used to try to free
|
---|
166 | resources and trigger object finalization, though no guarantee is made as
|
---|
167 | to what objects will be freed, if any.
|
---|
168 | \versionadded{2.3}
|
---|
169 | \end{funcdesc}
|
---|
170 |
|
---|
171 | \begin{datadesc}{exc_type}
|
---|
172 | \dataline{exc_value}
|
---|
173 | \dataline{exc_traceback}
|
---|
174 | \deprecated {1.5}
|
---|
175 | {Use \function{exc_info()} instead.}
|
---|
176 | Since they are global variables, they are not specific to the
|
---|
177 | current thread, so their use is not safe in a multi-threaded
|
---|
178 | program. When no exception is being handled, \code{exc_type} is set
|
---|
179 | to \code{None} and the other two are undefined.
|
---|
180 | \end{datadesc}
|
---|
181 |
|
---|
182 | \begin{datadesc}{exec_prefix}
|
---|
183 | A string giving the site-specific directory prefix where the
|
---|
184 | platform-dependent Python files are installed; by default, this is
|
---|
185 | also \code{'/usr/local'}. This can be set at build time with the
|
---|
186 | \longprogramopt{exec-prefix} argument to the \program{configure}
|
---|
187 | script. Specifically, all configuration files (e.g. the
|
---|
188 | \file{pyconfig.h} header file) are installed in the directory
|
---|
189 | \code{exec_prefix + '/lib/python\var{version}/config'}, and shared
|
---|
190 | library modules are installed in \code{exec_prefix +
|
---|
191 | '/lib/python\var{version}/lib-dynload'}, where \var{version} is
|
---|
192 | equal to \code{version[:3]}.
|
---|
193 | \end{datadesc}
|
---|
194 |
|
---|
195 | \begin{datadesc}{executable}
|
---|
196 | A string giving the name of the executable binary for the Python
|
---|
197 | interpreter, on systems where this makes sense.
|
---|
198 | \end{datadesc}
|
---|
199 |
|
---|
200 | \begin{funcdesc}{exit}{\optional{arg}}
|
---|
201 | Exit from Python. This is implemented by raising the
|
---|
202 | \exception{SystemExit} exception, so cleanup actions specified by
|
---|
203 | finally clauses of \keyword{try} statements are honored, and it is
|
---|
204 | possible to intercept the exit attempt at an outer level. The
|
---|
205 | optional argument \var{arg} can be an integer giving the exit status
|
---|
206 | (defaulting to zero), or another type of object. If it is an
|
---|
207 | integer, zero is considered ``successful termination'' and any
|
---|
208 | nonzero value is considered ``abnormal termination'' by shells and
|
---|
209 | the like. Most systems require it to be in the range 0-127, and
|
---|
210 | produce undefined results otherwise. Some systems have a convention
|
---|
211 | for assigning specific meanings to specific exit codes, but these
|
---|
212 | are generally underdeveloped; \UNIX{} programs generally use 2 for
|
---|
213 | command line syntax errors and 1 for all other kind of errors. If
|
---|
214 | another type of object is passed, \code{None} is equivalent to
|
---|
215 | passing zero, and any other object is printed to \code{sys.stderr}
|
---|
216 | and results in an exit code of 1. In particular,
|
---|
217 | \code{sys.exit("some error message")} is a quick way to exit a
|
---|
218 | program when an error occurs.
|
---|
219 | \end{funcdesc}
|
---|
220 |
|
---|
221 | \begin{datadesc}{exitfunc}
|
---|
222 | This value is not actually defined by the module, but can be set by
|
---|
223 | the user (or by a program) to specify a clean-up action at program
|
---|
224 | exit. When set, it should be a parameterless function. This
|
---|
225 | function will be called when the interpreter exits. Only one
|
---|
226 | function may be installed in this way; to allow multiple functions
|
---|
227 | which will be called at termination, use the \refmodule{atexit}
|
---|
228 | module. \note{The exit function is not called when the program is
|
---|
229 | killed by a signal, when a Python fatal internal error is detected,
|
---|
230 | or when \code{os._exit()} is called.}
|
---|
231 | \deprecated{2.4}{Use \refmodule{atexit} instead.}
|
---|
232 | \end{datadesc}
|
---|
233 |
|
---|
234 | \begin{funcdesc}{getcheckinterval}{}
|
---|
235 | Return the interpreter's ``check interval'';
|
---|
236 | see \function{setcheckinterval()}.
|
---|
237 | \versionadded{2.3}
|
---|
238 | \end{funcdesc}
|
---|
239 |
|
---|
240 | \begin{funcdesc}{getdefaultencoding}{}
|
---|
241 | Return the name of the current default string encoding used by the
|
---|
242 | Unicode implementation.
|
---|
243 | \versionadded{2.0}
|
---|
244 | \end{funcdesc}
|
---|
245 |
|
---|
246 | \begin{funcdesc}{getdlopenflags}{}
|
---|
247 | Return the current value of the flags that are used for
|
---|
248 | \cfunction{dlopen()} calls. The flag constants are defined in the
|
---|
249 | \refmodule{dl} and \module{DLFCN} modules.
|
---|
250 | Availability: \UNIX.
|
---|
251 | \versionadded{2.2}
|
---|
252 | \end{funcdesc}
|
---|
253 |
|
---|
254 | \begin{funcdesc}{getfilesystemencoding}{}
|
---|
255 | Return the name of the encoding used to convert Unicode filenames
|
---|
256 | into system file names, or \code{None} if the system default encoding
|
---|
257 | is used. The result value depends on the operating system:
|
---|
258 | \begin{itemize}
|
---|
259 | \item On Windows 9x, the encoding is ``mbcs''.
|
---|
260 | \item On Mac OS X, the encoding is ``utf-8''.
|
---|
261 | \item On \UNIX, the encoding is the user's preference
|
---|
262 | according to the result of nl_langinfo(CODESET), or \constant{None}
|
---|
263 | if the \code{nl_langinfo(CODESET)} failed.
|
---|
264 | \item On Windows NT+, file names are Unicode natively, so no conversion
|
---|
265 | is performed. \function{getfilesystemencoding()} still returns
|
---|
266 | \code{'mbcs'}, as this is the encoding that applications should use
|
---|
267 | when they explicitly want to convert Unicode strings to byte strings
|
---|
268 | that are equivalent when used as file names.
|
---|
269 | \end{itemize}
|
---|
270 | \versionadded{2.3}
|
---|
271 | \end{funcdesc}
|
---|
272 |
|
---|
273 | \begin{funcdesc}{getrefcount}{object}
|
---|
274 | Return the reference count of the \var{object}. The count returned
|
---|
275 | is generally one higher than you might expect, because it includes
|
---|
276 | the (temporary) reference as an argument to
|
---|
277 | \function{getrefcount()}.
|
---|
278 | \end{funcdesc}
|
---|
279 |
|
---|
280 | \begin{funcdesc}{getrecursionlimit}{}
|
---|
281 | Return the current value of the recursion limit, the maximum depth
|
---|
282 | of the Python interpreter stack. This limit prevents infinite
|
---|
283 | recursion from causing an overflow of the C stack and crashing
|
---|
284 | Python. It can be set by \function{setrecursionlimit()}.
|
---|
285 | \end{funcdesc}
|
---|
286 |
|
---|
287 | \begin{funcdesc}{_getframe}{\optional{depth}}
|
---|
288 | Return a frame object from the call stack. If optional integer
|
---|
289 | \var{depth} is given, return the frame object that many calls below
|
---|
290 | the top of the stack. If that is deeper than the call stack,
|
---|
291 | \exception{ValueError} is raised. The default for \var{depth} is
|
---|
292 | zero, returning the frame at the top of the call stack.
|
---|
293 |
|
---|
294 | This function should be used for internal and specialized purposes
|
---|
295 | only.
|
---|
296 | \end{funcdesc}
|
---|
297 |
|
---|
298 | \begin{funcdesc}{getwindowsversion}{}
|
---|
299 | Return a tuple containing five components, describing the Windows
|
---|
300 | version currently running. The elements are \var{major}, \var{minor},
|
---|
301 | \var{build}, \var{platform}, and \var{text}. \var{text} contains
|
---|
302 | a string while all other values are integers.
|
---|
303 |
|
---|
304 | \var{platform} may be one of the following values:
|
---|
305 |
|
---|
306 | \begin{tableii}{l|l}{constant}{Constant}{Platform}
|
---|
307 | \lineii{0 (VER_PLATFORM_WIN32s)} {Win32s on Windows 3.1}
|
---|
308 | \lineii{1 (VER_PLATFORM_WIN32_WINDOWS)}{Windows 95/98/ME}
|
---|
309 | \lineii{2 (VER_PLATFORM_WIN32_NT)} {Windows NT/2000/XP}
|
---|
310 | \lineii{3 (VER_PLATFORM_WIN32_CE)} {Windows CE}
|
---|
311 | \end{tableii}
|
---|
312 |
|
---|
313 | This function wraps the Win32 \cfunction{GetVersionEx()} function;
|
---|
314 | see the Microsoft documentation for more information about these
|
---|
315 | fields.
|
---|
316 |
|
---|
317 | Availability: Windows.
|
---|
318 | \versionadded{2.3}
|
---|
319 | \end{funcdesc}
|
---|
320 |
|
---|
321 | \begin{datadesc}{hexversion}
|
---|
322 | The version number encoded as a single integer. This is guaranteed
|
---|
323 | to increase with each version, including proper support for
|
---|
324 | non-production releases. For example, to test that the Python
|
---|
325 | interpreter is at least version 1.5.2, use:
|
---|
326 |
|
---|
327 | \begin{verbatim}
|
---|
328 | if sys.hexversion >= 0x010502F0:
|
---|
329 | # use some advanced feature
|
---|
330 | ...
|
---|
331 | else:
|
---|
332 | # use an alternative implementation or warn the user
|
---|
333 | ...
|
---|
334 | \end{verbatim}
|
---|
335 |
|
---|
336 | This is called \samp{hexversion} since it only really looks
|
---|
337 | meaningful when viewed as the result of passing it to the built-in
|
---|
338 | \function{hex()} function. The \code{version_info} value may be
|
---|
339 | used for a more human-friendly encoding of the same information.
|
---|
340 | \versionadded{1.5.2}
|
---|
341 | \end{datadesc}
|
---|
342 |
|
---|
343 | \begin{datadesc}{last_type}
|
---|
344 | \dataline{last_value}
|
---|
345 | \dataline{last_traceback}
|
---|
346 | These three variables are not always defined; they are set when an
|
---|
347 | exception is not handled and the interpreter prints an error message
|
---|
348 | and a stack traceback. Their intended use is to allow an
|
---|
349 | interactive user to import a debugger module and engage in
|
---|
350 | post-mortem debugging without having to re-execute the command that
|
---|
351 | caused the error. (Typical use is \samp{import pdb; pdb.pm()} to
|
---|
352 | enter the post-mortem debugger; see chapter~\ref{debugger}, ``The
|
---|
353 | Python Debugger,'' for more information.)
|
---|
354 |
|
---|
355 | The meaning of the variables is the same as that of the return
|
---|
356 | values from \function{exc_info()} above. (Since there is only one
|
---|
357 | interactive thread, thread-safety is not a concern for these
|
---|
358 | variables, unlike for \code{exc_type} etc.)
|
---|
359 | \end{datadesc}
|
---|
360 |
|
---|
361 | \begin{datadesc}{maxint}
|
---|
362 | The largest positive integer supported by Python's regular integer
|
---|
363 | type. This is at least 2**31-1. The largest negative integer is
|
---|
364 | \code{-maxint-1} --- the asymmetry results from the use of 2's
|
---|
365 | complement binary arithmetic.
|
---|
366 | \end{datadesc}
|
---|
367 |
|
---|
368 | \begin{datadesc}{maxunicode}
|
---|
369 | An integer giving the largest supported code point for a Unicode
|
---|
370 | character. The value of this depends on the configuration option
|
---|
371 | that specifies whether Unicode characters are stored as UCS-2 or
|
---|
372 | UCS-4.
|
---|
373 | \end{datadesc}
|
---|
374 |
|
---|
375 | \begin{datadesc}{modules}
|
---|
376 | This is a dictionary that maps module names to modules which have
|
---|
377 | already been loaded. This can be manipulated to force reloading of
|
---|
378 | modules and other tricks. Note that removing a module from this
|
---|
379 | dictionary is \emph{not} the same as calling
|
---|
380 | \function{reload()}\bifuncindex{reload} on the corresponding module
|
---|
381 | object.
|
---|
382 | \end{datadesc}
|
---|
383 |
|
---|
384 | \begin{datadesc}{path}
|
---|
385 | \indexiii{module}{search}{path}
|
---|
386 | A list of strings that specifies the search path for modules.
|
---|
387 | Initialized from the environment variable \envvar{PYTHONPATH}, plus an
|
---|
388 | installation-dependent default.
|
---|
389 |
|
---|
390 | As initialized upon program startup,
|
---|
391 | the first item of this list, \code{path[0]}, is the directory
|
---|
392 | containing the script that was used to invoke the Python
|
---|
393 | interpreter. If the script directory is not available (e.g. if the
|
---|
394 | interpreter is invoked interactively or if the script is read from
|
---|
395 | standard input), \code{path[0]} is the empty string, which directs
|
---|
396 | Python to search modules in the current directory first. Notice
|
---|
397 | that the script directory is inserted \emph{before} the entries
|
---|
398 | inserted as a result of \envvar{PYTHONPATH}.
|
---|
399 |
|
---|
400 | A program is free to modify this list for its own purposes.
|
---|
401 |
|
---|
402 | \versionchanged[Unicode strings are no longer ignored]{2.3}
|
---|
403 | \end{datadesc}
|
---|
404 |
|
---|
405 | \begin{datadesc}{platform}
|
---|
406 | This string contains a platform identifier, e.g. \code{'sunos5'} or
|
---|
407 | \code{'linux1'}. This can be used to append platform-specific
|
---|
408 | components to \code{path}, for instance.
|
---|
409 | \end{datadesc}
|
---|
410 |
|
---|
411 | \begin{datadesc}{prefix}
|
---|
412 | A string giving the site-specific directory prefix where the
|
---|
413 | platform independent Python files are installed; by default, this is
|
---|
414 | the string \code{'/usr/local'}. This can be set at build time with
|
---|
415 | the \longprogramopt{prefix} argument to the \program{configure}
|
---|
416 | script. The main collection of Python library modules is installed
|
---|
417 | in the directory \code{prefix + '/lib/python\var{version}'} while
|
---|
418 | the platform independent header files (all except \file{pyconfig.h})
|
---|
419 | are stored in \code{prefix + '/include/python\var{version}'}, where
|
---|
420 | \var{version} is equal to \code{version[:3]}.
|
---|
421 | \end{datadesc}
|
---|
422 |
|
---|
423 | \begin{datadesc}{ps1}
|
---|
424 | \dataline{ps2}
|
---|
425 | \index{interpreter prompts}
|
---|
426 | \index{prompts, interpreter}
|
---|
427 | Strings specifying the primary and secondary prompt of the
|
---|
428 | interpreter. These are only defined if the interpreter is in
|
---|
429 | interactive mode. Their initial values in this case are
|
---|
430 | \code{'>>>~'} and \code{'...~'}. If a non-string object is
|
---|
431 | assigned to either variable, its \function{str()} is re-evaluated
|
---|
432 | each time the interpreter prepares to read a new interactive
|
---|
433 | command; this can be used to implement a dynamic prompt.
|
---|
434 | \end{datadesc}
|
---|
435 |
|
---|
436 | \begin{funcdesc}{setcheckinterval}{interval}
|
---|
437 | Set the interpreter's ``check interval''. This integer value
|
---|
438 | determines how often the interpreter checks for periodic things such
|
---|
439 | as thread switches and signal handlers. The default is \code{100},
|
---|
440 | meaning the check is performed every 100 Python virtual instructions.
|
---|
441 | Setting it to a larger value may increase performance for programs
|
---|
442 | using threads. Setting it to a value \code{<=} 0 checks every
|
---|
443 | virtual instruction, maximizing responsiveness as well as overhead.
|
---|
444 | \end{funcdesc}
|
---|
445 |
|
---|
446 | \begin{funcdesc}{setdefaultencoding}{name}
|
---|
447 | Set the current default string encoding used by the Unicode
|
---|
448 | implementation. If \var{name} does not match any available
|
---|
449 | encoding, \exception{LookupError} is raised. This function is only
|
---|
450 | intended to be used by the \refmodule{site} module implementation
|
---|
451 | and, where needed, by \module{sitecustomize}. Once used by the
|
---|
452 | \refmodule{site} module, it is removed from the \module{sys}
|
---|
453 | module's namespace.
|
---|
454 | % Note that \refmodule{site} is not imported if
|
---|
455 | % the \programopt{-S} option is passed to the interpreter, in which
|
---|
456 | % case this function will remain available.
|
---|
457 | \versionadded{2.0}
|
---|
458 | \end{funcdesc}
|
---|
459 |
|
---|
460 | \begin{funcdesc}{setdlopenflags}{n}
|
---|
461 | Set the flags used by the interpreter for \cfunction{dlopen()}
|
---|
462 | calls, such as when the interpreter loads extension modules. Among
|
---|
463 | other things, this will enable a lazy resolving of symbols when
|
---|
464 | importing a module, if called as \code{sys.setdlopenflags(0)}. To
|
---|
465 | share symbols across extension modules, call as
|
---|
466 | \code{sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)}. Symbolic
|
---|
467 | names for the flag modules can be either found in the \refmodule{dl}
|
---|
468 | module, or in the \module{DLFCN} module. If \module{DLFCN} is not
|
---|
469 | available, it can be generated from \file{/usr/include/dlfcn.h}
|
---|
470 | using the \program{h2py} script.
|
---|
471 | Availability: \UNIX.
|
---|
472 | \versionadded{2.2}
|
---|
473 | \end{funcdesc}
|
---|
474 |
|
---|
475 | \begin{funcdesc}{setprofile}{profilefunc}
|
---|
476 | Set the system's profile function,\index{profile function} which
|
---|
477 | allows you to implement a Python source code profiler in
|
---|
478 | Python.\index{profiler} See chapter~\ref{profile} for more
|
---|
479 | information on the Python profiler. The system's profile function
|
---|
480 | is called similarly to the system's trace function (see
|
---|
481 | \function{settrace()}), but it isn't called for each executed line
|
---|
482 | of code (only on call and return, but the return event is reported
|
---|
483 | even when an exception has been set). The function is
|
---|
484 | thread-specific, but there is no way for the profiler to know about
|
---|
485 | context switches between threads, so it does not make sense to use
|
---|
486 | this in the presence of multiple threads.
|
---|
487 | Also, its return value is not used, so it can simply return
|
---|
488 | \code{None}.
|
---|
489 | \end{funcdesc}
|
---|
490 |
|
---|
491 | \begin{funcdesc}{setrecursionlimit}{limit}
|
---|
492 | Set the maximum depth of the Python interpreter stack to
|
---|
493 | \var{limit}. This limit prevents infinite recursion from causing an
|
---|
494 | overflow of the C stack and crashing Python.
|
---|
495 |
|
---|
496 | The highest possible limit is platform-dependent. A user may need
|
---|
497 | to set the limit higher when she has a program that requires deep
|
---|
498 | recursion and a platform that supports a higher limit. This should
|
---|
499 | be done with care, because a too-high limit can lead to a crash.
|
---|
500 | \end{funcdesc}
|
---|
501 |
|
---|
502 | \begin{funcdesc}{settrace}{tracefunc}
|
---|
503 | Set the system's trace function,\index{trace function} which allows
|
---|
504 | you to implement a Python source code debugger in Python. See
|
---|
505 | section \ref{debugger-hooks}, ``How It Works,'' in the chapter on
|
---|
506 | the Python debugger.\index{debugger} The function is
|
---|
507 | thread-specific; for a debugger to support multiple threads, it must
|
---|
508 | be registered using \function{settrace()} for each thread being
|
---|
509 | debugged. \note{The \function{settrace()} function is intended only
|
---|
510 | for implementing debuggers, profilers, coverage tools and the like.
|
---|
511 | Its behavior is part of the implementation platform, rather than
|
---|
512 | part of the language definition, and thus may not be available in
|
---|
513 | all Python implementations.}
|
---|
514 | \end{funcdesc}
|
---|
515 |
|
---|
516 | \begin{funcdesc}{settscdump}{on_flag}
|
---|
517 | Activate dumping of VM measurements using the Pentium timestamp
|
---|
518 | counter, if \var{on_flag} is true. Deactivate these dumps if
|
---|
519 | \var{on_flag} is off. The function is available only if Python
|
---|
520 | was compiled with \longprogramopt{with-tsc}. To understand the
|
---|
521 | output of this dump, read \file{Python/ceval.c} in the Python
|
---|
522 | sources.
|
---|
523 | \versionadded{2.4}
|
---|
524 | \end{funcdesc}
|
---|
525 |
|
---|
526 | \begin{datadesc}{stdin}
|
---|
527 | \dataline{stdout}
|
---|
528 | \dataline{stderr}
|
---|
529 | File objects corresponding to the interpreter's standard input,
|
---|
530 | output and error streams. \code{stdin} is used for all interpreter
|
---|
531 | input except for scripts but including calls to
|
---|
532 | \function{input()}\bifuncindex{input} and
|
---|
533 | \function{raw_input()}\bifuncindex{raw_input}. \code{stdout} is
|
---|
534 | used for the output of \keyword{print} and expression statements and
|
---|
535 | for the prompts of \function{input()} and \function{raw_input()}.
|
---|
536 | The interpreter's own prompts and (almost all of) its error messages
|
---|
537 | go to \code{stderr}. \code{stdout} and \code{stderr} needn't be
|
---|
538 | built-in file objects: any object is acceptable as long as it has a
|
---|
539 | \method{write()} method that takes a string argument. (Changing
|
---|
540 | these objects doesn't affect the standard I/O streams of processes
|
---|
541 | executed by \function{os.popen()}, \function{os.system()} or the
|
---|
542 | \function{exec*()} family of functions in the \refmodule{os}
|
---|
543 | module.)
|
---|
544 | \end{datadesc}
|
---|
545 |
|
---|
546 | \begin{datadesc}{__stdin__}
|
---|
547 | \dataline{__stdout__}
|
---|
548 | \dataline{__stderr__}
|
---|
549 | These objects contain the original values of \code{stdin},
|
---|
550 | \code{stderr} and \code{stdout} at the start of the program. They
|
---|
551 | are used during finalization, and could be useful to restore the
|
---|
552 | actual files to known working file objects in case they have been
|
---|
553 | overwritten with a broken object.
|
---|
554 | \end{datadesc}
|
---|
555 |
|
---|
556 | \begin{datadesc}{tracebacklimit}
|
---|
557 | When this variable is set to an integer value, it determines the
|
---|
558 | maximum number of levels of traceback information printed when an
|
---|
559 | unhandled exception occurs. The default is \code{1000}. When set
|
---|
560 | to \code{0} or less, all traceback information is suppressed and
|
---|
561 | only the exception type and value are printed.
|
---|
562 | \end{datadesc}
|
---|
563 |
|
---|
564 | \begin{datadesc}{version}
|
---|
565 | A string containing the version number of the Python interpreter
|
---|
566 | plus additional information on the build number and compiler used.
|
---|
567 | It has a value of the form \code{'\var{version}
|
---|
568 | (\#\var{build_number}, \var{build_date}, \var{build_time})
|
---|
569 | [\var{compiler}]'}. The first three characters are used to identify
|
---|
570 | the version in the installation directories (where appropriate on
|
---|
571 | each platform). An example:
|
---|
572 |
|
---|
573 | \begin{verbatim}
|
---|
574 | >>> import sys
|
---|
575 | >>> sys.version
|
---|
576 | '1.5.2 (#0 Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)]'
|
---|
577 | \end{verbatim}
|
---|
578 | \end{datadesc}
|
---|
579 |
|
---|
580 | \begin{datadesc}{api_version}
|
---|
581 | The C API version for this interpreter. Programmers may find this useful
|
---|
582 | when debugging version conflicts between Python and extension
|
---|
583 | modules. \versionadded{2.3}
|
---|
584 | \end{datadesc}
|
---|
585 |
|
---|
586 | \begin{datadesc}{version_info}
|
---|
587 | A tuple containing the five components of the version number:
|
---|
588 | \var{major}, \var{minor}, \var{micro}, \var{releaselevel}, and
|
---|
589 | \var{serial}. All values except \var{releaselevel} are integers;
|
---|
590 | the release level is \code{'alpha'}, \code{'beta'},
|
---|
591 | \code{'candidate'}, or \code{'final'}. The \code{version_info}
|
---|
592 | value corresponding to the Python version 2.0 is \code{(2, 0, 0,
|
---|
593 | 'final', 0)}.
|
---|
594 | \versionadded{2.0}
|
---|
595 | \end{datadesc}
|
---|
596 |
|
---|
597 | \begin{datadesc}{warnoptions}
|
---|
598 | This is an implementation detail of the warnings framework; do not
|
---|
599 | modify this value. Refer to the \refmodule{warnings} module for
|
---|
600 | more information on the warnings framework.
|
---|
601 | \end{datadesc}
|
---|
602 |
|
---|
603 | \begin{datadesc}{winver}
|
---|
604 | The version number used to form registry keys on Windows platforms.
|
---|
605 | This is stored as string resource 1000 in the Python DLL. The value
|
---|
606 | is normally the first three characters of \constant{version}. It is
|
---|
607 | provided in the \module{sys} module for informational purposes;
|
---|
608 | modifying this value has no effect on the registry keys used by
|
---|
609 | Python.
|
---|
610 | Availability: Windows.
|
---|
611 | \end{datadesc}
|
---|
612 |
|
---|
613 |
|
---|
614 | \begin{seealso}
|
---|
615 | \seemodule{site}
|
---|
616 | {This describes how to use .pth files to extend \code{sys.path}.}
|
---|
617 | \end{seealso}
|
---|