| \section{\module{sys} --- | 
 |          System-specific parameters and functions} | 
 |  | 
 | \declaremodule{builtin}{sys} | 
 | \modulesynopsis{Access system-specific parameters and functions.} | 
 |  | 
 | This module provides access to some variables used or maintained by the | 
 | interpreter and to functions that interact strongly with the interpreter. | 
 | It is always available. | 
 |  | 
 |  | 
 | \begin{datadesc}{argv} | 
 |   The list of command line arguments passed to a Python script. | 
 |   \code{argv[0]} is the script name (it is operating system dependent | 
 |   whether this is a full pathname or not).  If the command was | 
 |   executed using the \programopt{-c} command line option to the | 
 |   interpreter, \code{argv[0]} is set to the string \code{'-c'}.  If no | 
 |   script name was passed to the Python interpreter, \code{argv} has | 
 |   zero length. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{byteorder} | 
 |   An indicator of the native byte order.  This will have the value | 
 |   \code{'big'} on big-endian (most-signigicant byte first) platforms, | 
 |   and \code{'little'} on little-endian (least-significant byte first) | 
 |   platforms. | 
 |   \versionadded{2.0} | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{builtin_module_names} | 
 |   A tuple of strings giving the names of all modules that are compiled | 
 |   into this Python interpreter.  (This information is not available in | 
 |   any other way --- \code{modules.keys()} only lists the imported | 
 |   modules.) | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{copyright} | 
 |   A string containing the copyright pertaining to the Python | 
 |   interpreter. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{dllhandle} | 
 |   Integer specifying the handle of the Python DLL. | 
 |   Availability: Windows. | 
 | \end{datadesc} | 
 |  | 
 | \begin{funcdesc}{displayhook}{\var{value}} | 
 |   If \var{value} is not \code{None}, this function prints it to | 
 |   \code{sys.stdout}, and saves it in \code{__builtin__._}. | 
 |  | 
 |   \code{sys.displayhook} is called on the result of evaluating an | 
 |   expression entered in an interactive Python session.  The display of | 
 |   these values can be customized by assigning another one-argument | 
 |   function to \code{sys.displayhook}. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{excepthook}{\var{type}, \var{value}, \var{traceback}} | 
 |   This function prints out a given traceback and exception to | 
 |   \code{sys.stderr}. | 
 |  | 
 |   When an exception is raised and uncaught, the interpreter calls | 
 |   \code{sys.excepthook} with three arguments, the exception class, | 
 |   exception instance, and a traceback object.  In an interactive | 
 |   session this happens just before control is returned to the prompt; | 
 |   in a Python program this happens just before the program exits.  The | 
 |   handling of such top-level exceptions can be customized by assigning | 
 |   another three-argument function to \code{sys.excepthook}. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{datadesc}{__displayhook__} | 
 | \dataline{__excepthook__} | 
 |   These objects contain the original values of \code{displayhook} and | 
 |   \code{excepthook} at the start of the program.  They are saved so | 
 |   that \code{displayhook} and \code{excepthook} can be restored in | 
 |   case they happen to get replaced with broken objects. | 
 | \end{datadesc} | 
 |  | 
 | \begin{funcdesc}{exc_info}{} | 
 |   This function returns a tuple of three values that give information | 
 |   about the exception that is currently being handled.  The | 
 |   information returned is specific both to the current thread and to | 
 |   the current stack frame.  If the current stack frame is not handling | 
 |   an exception, the information is taken from the calling stack frame, | 
 |   or its caller, and so on until a stack frame is found that is | 
 |   handling an exception.  Here, ``handling an exception'' is defined | 
 |   as ``executing or having executed an except clause.''  For any stack | 
 |   frame, only information about the most recently handled exception is | 
 |   accessible. | 
 |  | 
 |   If no exception is being handled anywhere on the stack, a tuple | 
 |   containing three \code{None} values is returned.  Otherwise, the | 
 |   values returned are \code{(\var{type}, \var{value}, | 
 |   \var{traceback})}.  Their meaning is: \var{type} gets the exception | 
 |   type of the exception being handled (a class object); | 
 |   \var{value} gets the exception parameter (its \dfn{associated value} | 
 |   or the second argument to \keyword{raise}, which is always a class | 
 |   instance if the exception type is a class object); \var{traceback} | 
 |   gets a traceback object (see the Reference Manual) which | 
 |   encapsulates the call stack at the point where the exception | 
 |   originally occurred.  \obindex{traceback} | 
 |  | 
 |   If \function{exc_clear()} is called, this function will return three | 
 |   \code{None} values until either another exception is raised in the | 
 |   current thread or the execution stack returns to a frame where | 
 |   another exception is being handled. | 
 |  | 
 |   \warning{Assigning the \var{traceback} return value to a | 
 |   local variable in a function that is handling an exception will | 
 |   cause a circular reference.  This will prevent anything referenced | 
 |   by a local variable in the same function or by the traceback from | 
 |   being garbage collected.  Since most functions don't need access to | 
 |   the traceback, the best solution is to use something like | 
 |   \code{exctype, value = sys.exc_info()[:2]} to extract only the | 
 |   exception type and value.  If you do need the traceback, make sure | 
 |   to delete it after use (best done with a \keyword{try} | 
 |   ... \keyword{finally} statement) or to call \function{exc_info()} in | 
 |   a function that does not itself handle an exception.} \note{Beginning | 
 |   with Python 2.2, such cycles are automatically reclaimed when garbage | 
 |   collection is enabled and they become unreachable, but it remains more | 
 |   efficient to avoid creating cycles.} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{exc_clear}{} | 
 |   This function clears all information relating to the current or last | 
 |   exception that occured in the current thread.  After calling this | 
 |   function, \function{exc_info()} will return three \code{None} values until | 
 |   another exception is raised in the current thread or the execution stack | 
 |   returns to a frame where another exception is being handled. | 
 |    | 
 |   This function is only needed in only a few obscure situations.  These | 
 |   include logging and error handling systems that report information on the | 
 |   last or current exception.  This function can also be used to try to free | 
 |   resources and trigger object finalization, though no guarantee is made as | 
 |   to what objects will be freed, if any. | 
 | \versionadded{2.3} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{datadesc}{exc_type} | 
 | \dataline{exc_value} | 
 | \dataline{exc_traceback} | 
 | \deprecated {1.5} | 
 |             {Use \function{exc_info()} instead.} | 
 |   Since they are global variables, they are not specific to the | 
 |   current thread, so their use is not safe in a multi-threaded | 
 |   program.  When no exception is being handled, \code{exc_type} is set | 
 |   to \code{None} and the other two are undefined. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{exec_prefix} | 
 |   A string giving the site-specific directory prefix where the | 
 |   platform-dependent Python files are installed; by default, this is | 
 |   also \code{'/usr/local'}.  This can be set at build time with the | 
 |   \longprogramopt{exec-prefix} argument to the \program{configure} | 
 |   script.  Specifically, all configuration files (e.g. the | 
 |   \file{pyconfig.h} header file) are installed in the directory | 
 |   \code{exec_prefix + '/lib/python\var{version}/config'}, and shared | 
 |   library modules are installed in \code{exec_prefix + | 
 |   '/lib/python\var{version}/lib-dynload'}, where \var{version} is | 
 |   equal to \code{version[:3]}. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{executable} | 
 |   A string giving the name of the executable binary for the Python | 
 |   interpreter, on systems where this makes sense. | 
 | \end{datadesc} | 
 |  | 
 | \begin{funcdesc}{exit}{\optional{arg}} | 
 |   Exit from Python.  This is implemented by raising the | 
 |   \exception{SystemExit} exception, so cleanup actions specified by | 
 |   finally clauses of \keyword{try} statements are honored, and it is | 
 |   possible to intercept the exit attempt at an outer level.  The | 
 |   optional argument \var{arg} can be an integer giving the exit status | 
 |   (defaulting to zero), or another type of object.  If it is an | 
 |   integer, zero is considered ``successful termination'' and any | 
 |   nonzero value is considered ``abnormal termination'' by shells and | 
 |   the like.  Most systems require it to be in the range 0-127, and | 
 |   produce undefined results otherwise.  Some systems have a convention | 
 |   for assigning specific meanings to specific exit codes, but these | 
 |   are generally underdeveloped; \UNIX{} programs generally use 2 for | 
 |   command line syntax errors and 1 for all other kind of errors.  If | 
 |   another type of object is passed, \code{None} is equivalent to | 
 |   passing zero, and any other object is printed to \code{sys.stderr} | 
 |   and results in an exit code of 1.  In particular, | 
 |   \code{sys.exit("some error message")} is a quick way to exit a | 
 |   program when an error occurs. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{datadesc}{exitfunc} | 
 |   This value is not actually defined by the module, but can be set by | 
 |   the user (or by a program) to specify a clean-up action at program | 
 |   exit.  When set, it should be a parameterless function.  This | 
 |   function will be called when the interpreter exits.  Only one | 
 |   function may be installed in this way; to allow multiple functions | 
 |   which will be called at termination, use the \refmodule{atexit} | 
 |   module.  \note{The exit function is not called when the program is | 
 |   killed by a signal, when a Python fatal internal error is detected, | 
 |   or when \code{os._exit()} is called.} | 
 | \end{datadesc} | 
 |  | 
 | \begin{funcdesc}{getcheckinterval}{} | 
 |   Return the interpreter's ``check interval''; | 
 |   see \function{setcheckinterval()}. | 
 |   \versionadded{2.3} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{getdefaultencoding}{} | 
 |   Return the name of the current default string encoding used by the | 
 |   Unicode implementation. | 
 |   \versionadded{2.0} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{getdlopenflags}{} | 
 |   Return the current value of the flags that are used for | 
 |   \cfunction{dlopen()} calls. The flag constants are defined in the | 
 |   \refmodule{dl} and \module{DLFCN} modules. | 
 |   Availability: \UNIX. | 
 |   \versionadded{2.2} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{getfilesystemencoding}{} | 
 |   Return the name of the encoding used to convert Unicode filenames | 
 |   into system file names, or \code{None} if the system default encoding | 
 |   is used. The result value depends on the operating system: | 
 | \begin{itemize} | 
 | \item On Windows 9x, the encoding is ``mbcs''. | 
 | \item On Mac OS X, the encoding is ``utf-8''. | 
 | \item On Unix, the encoding is the user's preference  | 
 |       according to the result of nl_langinfo(CODESET), or None if | 
 |       the nl_langinfo(CODESET) failed. | 
 | \item On Windows NT+, file names are Unicode natively, so no conversion | 
 |       is performed. | 
 | \end{itemize} | 
 |   \versionadded{2.3} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{getrefcount}{object} | 
 |   Return the reference count of the \var{object}.  The count returned | 
 |   is generally one higher than you might expect, because it includes | 
 |   the (temporary) reference as an argument to | 
 |   \function{getrefcount()}. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{getrecursionlimit}{} | 
 |   Return the current value of the recursion limit, the maximum depth | 
 |   of the Python interpreter stack.  This limit prevents infinite | 
 |   recursion from causing an overflow of the C stack and crashing | 
 |   Python.  It can be set by \function{setrecursionlimit()}. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{_getframe}{\optional{depth}} | 
 |   Return a frame object from the call stack.  If optional integer | 
 |   \var{depth} is given, return the frame object that many calls below | 
 |   the top of the stack.  If that is deeper than the call stack, | 
 |   \exception{ValueError} is raised.  The default for \var{depth} is | 
 |   zero, returning the frame at the top of the call stack. | 
 |  | 
 |   This function should be used for internal and specialized purposes | 
 |   only. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{getwindowsversion}{} | 
 |   Return a tuple containing five components, describing the Windows  | 
 |   version currently running.  The elements are \var{major}, \var{minor},  | 
 |   \var{build}, \var{platform}, and \var{text}.  \var{text} contains | 
 |   a string while all other values are integers. | 
 |  | 
 |   \var{platform} may be one of the following values: | 
 |   \begin{list}{}{\leftmargin 0.7in \labelwidth 0.65in} | 
 |     \item[0 (\constant{VER_PLATFORM_WIN32s})] | 
 |       Win32s on Windows 3.1. | 
 |     \item[1 (\constant{VER_PLATFORM_WIN32_WINDOWS})]  | 
 |       Windows 95/98/ME | 
 |     \item[2 (\constant{VER_PLATFORM_WIN32_NT})]  | 
 |       Windows NT/2000/XP | 
 |     \item[3 (\constant{VER_PLATFORM_WIN32_CE})]  | 
 |       Windows CE. | 
 |   \end{list} | 
 |    | 
 |   This function wraps the Win32 \function{GetVersionEx()} function; | 
 |   see the Microsoft Documentation for more information about these | 
 |   fields. | 
 |  | 
 |   Availability: Windows. | 
 |   \versionadded{2.3} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{datadesc}{hexversion} | 
 |   The version number encoded as a single integer.  This is guaranteed | 
 |   to increase with each version, including proper support for | 
 |   non-production releases.  For example, to test that the Python | 
 |   interpreter is at least version 1.5.2, use: | 
 |  | 
 | \begin{verbatim} | 
 | if sys.hexversion >= 0x010502F0: | 
 |     # use some advanced feature | 
 |     ... | 
 | else: | 
 |     # use an alternative implementation or warn the user | 
 |     ... | 
 | \end{verbatim} | 
 |  | 
 |   This is called \samp{hexversion} since it only really looks | 
 |   meaningful when viewed as the result of passing it to the built-in | 
 |   \function{hex()} function.  The \code{version_info} value may be | 
 |   used for a more human-friendly encoding of the same information. | 
 |   \versionadded{1.5.2} | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{last_type} | 
 | \dataline{last_value} | 
 | \dataline{last_traceback} | 
 |   These three variables are not always defined; they are set when an | 
 |   exception is not handled and the interpreter prints an error message | 
 |   and a stack traceback.  Their intended use is to allow an | 
 |   interactive user to import a debugger module and engage in | 
 |   post-mortem debugging without having to re-execute the command that | 
 |   caused the error.  (Typical use is \samp{import pdb; pdb.pm()} to | 
 |   enter the post-mortem debugger; see chapter \ref{debugger}, ``The | 
 |   Python Debugger,'' for more information.) | 
 |  | 
 |   The meaning of the variables is the same as that of the return | 
 |   values from \function{exc_info()} above.  (Since there is only one | 
 |   interactive thread, thread-safety is not a concern for these | 
 |   variables, unlike for \code{exc_type} etc.) | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{maxint} | 
 |   The largest positive integer supported by Python's regular integer | 
 |   type.  This is at least 2**31-1.  The largest negative integer is | 
 |   \code{-maxint-1} --- the asymmetry results from the use of 2's | 
 |   complement binary arithmetic. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{maxunicode} | 
 |   An integer giving the largest supported code point for a Unicode | 
 |   character.  The value of this depends on the configuration option | 
 |   that specifies whether Unicode characters are stored as UCS-2 or | 
 |   UCS-4. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{modules} | 
 |   This is a dictionary that maps module names to modules which have | 
 |   already been loaded.  This can be manipulated to force reloading of | 
 |   modules and other tricks.  Note that removing a module from this | 
 |   dictionary is \emph{not} the same as calling | 
 |   \function{reload()}\bifuncindex{reload} on the corresponding module | 
 |   object. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{path} | 
 | \indexiii{module}{search}{path} | 
 |   A list of strings that specifies the search path for modules. | 
 |   Initialized from the environment variable \envvar{PYTHONPATH}, plus an | 
 |   installation-dependent default. | 
 |  | 
 |   As initialized upon program startup, | 
 |   the first item of this list, \code{path[0]}, is the directory | 
 |   containing the script that was used to invoke the Python | 
 |   interpreter.  If the script directory is not available (e.g.  if the | 
 |   interpreter is invoked interactively or if the script is read from | 
 |   standard input), \code{path[0]} is the empty string, which directs | 
 |   Python to search modules in the current directory first.  Notice | 
 |   that the script directory is inserted \emph{before} the entries | 
 |   inserted as a result of \envvar{PYTHONPATH}. | 
 |  | 
 |   A program is free to modify this list for its own purposes. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{platform} | 
 |   This string contains a platform identifier, e.g. \code{'sunos5'} or | 
 |   \code{'linux1'}.  This can be used to append platform-specific | 
 |   components to \code{path}, for instance. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{prefix} | 
 |   A string giving the site-specific directory prefix where the | 
 |   platform independent Python files are installed; by default, this is | 
 |   the string \code{'/usr/local'}.  This can be set at build time with | 
 |   the \longprogramopt{prefix} argument to the \program{configure} | 
 |   script.  The main collection of Python library modules is installed | 
 |   in the directory \code{prefix + '/lib/python\var{version}'} while | 
 |   the platform independent header files (all except \file{pyconfig.h}) | 
 |   are stored in \code{prefix + '/include/python\var{version}'}, where | 
 |   \var{version} is equal to \code{version[:3]}. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{ps1} | 
 | \dataline{ps2} | 
 | \index{interpreter prompts} | 
 | \index{prompts, interpreter} | 
 |   Strings specifying the primary and secondary prompt of the | 
 |   interpreter.  These are only defined if the interpreter is in | 
 |   interactive mode.  Their initial values in this case are | 
 |   \code{'>\code{>}> '} and \code{'... '}.  If a non-string object is | 
 |   assigned to either variable, its \function{str()} is re-evaluated | 
 |   each time the interpreter prepares to read a new interactive | 
 |   command; this can be used to implement a dynamic prompt. | 
 | \end{datadesc} | 
 |  | 
 | \begin{funcdesc}{setcheckinterval}{interval} | 
 |   Set the interpreter's ``check interval''.  This integer value | 
 |   determines how often the interpreter checks for periodic things such | 
 |   as thread switches and signal handlers.  The default is \code{100}, | 
 |   meaning the check is performed every 100 Python virtual instructions. | 
 |   Setting it to a larger value may increase performance for programs | 
 |   using threads.  Setting it to a value \code{<=} 0 checks every | 
 |   virtual instruction, maximizing responsiveness as well as overhead. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{setdefaultencoding}{name} | 
 |   Set the current default string encoding used by the Unicode | 
 |   implementation.  If \var{name} does not match any available | 
 |   encoding, \exception{LookupError} is raised.  This function is only | 
 |   intended to be used by the \refmodule{site} module implementation | 
 |   and, where needed, by \module{sitecustomize}.  Once used by the | 
 |   \refmodule{site} module, it is removed from the \module{sys} | 
 |   module's namespace. | 
 | %  Note that \refmodule{site} is not imported if | 
 | %  the \programopt{-S} option is passed to the interpreter, in which | 
 | %  case this function will remain available. | 
 |   \versionadded{2.0} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{setdlopenflags}{n} | 
 |   Set the flags used by the interpreter for \cfunction{dlopen()} | 
 |   calls, such as when the interpreter loads extension modules.  Among | 
 |   other things, this will enable a lazy resolving of symbols when | 
 |   importing a module, if called as \code{sys.setdlopenflags(0)}.  To | 
 |   share symbols across extension modules, call as | 
 |   \code{sys.setdlopenflags(dl.RTLD_NOW | dl.RTLD_GLOBAL)}.  Symbolic | 
 |   names for the flag modules can be either found in the \refmodule{dl} | 
 |   module, or in the \module{DLFCN} module. If \module{DLFCN} is not | 
 |   available, it can be generated from \file{/usr/include/dlfcn.h} | 
 |   using the \program{h2py} script. | 
 |   Availability: \UNIX. | 
 |   \versionadded{2.2} | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{setprofile}{profilefunc} | 
 |   Set the system's profile function,\index{profile function} which | 
 |   allows you to implement a Python source code profiler in | 
 |   Python.\index{profiler}  See chapter \ref{profile} for more | 
 |   information on the Python profiler.  The system's profile function | 
 |   is called similarly to the system's trace function (see | 
 |   \function{settrace()}), but it isn't called for each executed line | 
 |   of code (only on call and return, but the return event is reported | 
 |   even when an exception has been set).  The function is | 
 |   thread-specific, but there is no way for the profiler to know about | 
 |   context switches between threads, so it does not make sense to use | 
 |   this in the presence of multiple threads. | 
 |   Also, its return value is not used, so it can simply return | 
 |   \code{None}. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{setrecursionlimit}{limit} | 
 |   Set the maximum depth of the Python interpreter stack to | 
 |   \var{limit}.  This limit prevents infinite recursion from causing an | 
 |   overflow of the C stack and crashing Python. | 
 |  | 
 |   The highest possible limit is platform-dependent.  A user may need | 
 |   to set the limit higher when she has a program that requires deep | 
 |   recursion and a platform that supports a higher limit.  This should | 
 |   be done with care, because a too-high limit can lead to a crash. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{funcdesc}{settrace}{tracefunc} | 
 |   Set the system's trace function,\index{trace function} which allows | 
 |   you to implement a Python source code debugger in Python.  See | 
 |   section \ref{debugger-hooks}, ``How It Works,'' in the chapter on | 
 |   the Python debugger.\index{debugger}  The function is | 
 |   thread-specific; for a debugger to support multiple threads, it must | 
 |   be registered using \function{settrace()} for each thread being | 
 |   debugged. | 
 | \end{funcdesc} | 
 |  | 
 | \begin{datadesc}{stdin} | 
 | \dataline{stdout} | 
 | \dataline{stderr} | 
 |   File objects corresponding to the interpreter's standard input, | 
 |   output and error streams.  \code{stdin} is used for all interpreter | 
 |   input except for scripts but including calls to | 
 |   \function{input()}\bifuncindex{input} and | 
 |   \function{raw_input()}\bifuncindex{raw_input}.  \code{stdout} is | 
 |   used for the output of \keyword{print} and expression statements and | 
 |   for the prompts of \function{input()} and \function{raw_input()}. | 
 |   The interpreter's own prompts and (almost all of) its error messages | 
 |   go to \code{stderr}.  \code{stdout} and \code{stderr} needn't be | 
 |   built-in file objects: any object is acceptable as long as it has a | 
 |   \method{write()} method that takes a string argument.  (Changing | 
 |   these objects doesn't affect the standard I/O streams of processes | 
 |   executed by \function{os.popen()}, \function{os.system()} or the | 
 |   \function{exec*()} family of functions in the \refmodule{os} | 
 |   module.) | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{__stdin__} | 
 | \dataline{__stdout__} | 
 | \dataline{__stderr__} | 
 |   These objects contain the original values of \code{stdin}, | 
 |   \code{stderr} and \code{stdout} at the start of the program.  They | 
 |   are used during finalization, and could be useful to restore the | 
 |   actual files to known working file objects in case they have been | 
 |   overwritten with a broken object. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{tracebacklimit} | 
 |   When this variable is set to an integer value, it determines the | 
 |   maximum number of levels of traceback information printed when an | 
 |   unhandled exception occurs.  The default is \code{1000}.  When set | 
 |   to \code{0} or less, all traceback information is suppressed and | 
 |   only the exception type and value are printed. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{version} | 
 |   A string containing the version number of the Python interpreter | 
 |   plus additional information on the build number and compiler used. | 
 |   It has a value of the form \code{'\var{version} | 
 |   (\#\var{build_number}, \var{build_date}, \var{build_time}) | 
 |   [\var{compiler}]'}.  The first three characters are used to identify | 
 |   the version in the installation directories (where appropriate on | 
 |   each platform).  An example: | 
 |  | 
 | \begin{verbatim} | 
 | >>> import sys | 
 | >>> sys.version | 
 | '1.5.2 (#0 Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)]' | 
 | \end{verbatim} | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{api_version} | 
 |   The C API version for this interpreter.  Programmers may find this useful | 
 |   when debugging version conflicts between Python and extension | 
 |   modules. \versionadded{2.3} | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{version_info} | 
 |   A tuple containing the five components of the version number: | 
 |   \var{major}, \var{minor}, \var{micro}, \var{releaselevel}, and | 
 |   \var{serial}.  All values except \var{releaselevel} are integers; | 
 |   the release level is \code{'alpha'}, \code{'beta'}, | 
 |   \code{'candidate'}, or \code{'final'}.  The \code{version_info} | 
 |   value corresponding to the Python version 2.0 is \code{(2, 0, 0, | 
 |   'final', 0)}. | 
 |   \versionadded{2.0} | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{warnoptions} | 
 |   This is an implementation detail of the warnings framework; do not | 
 |   modify this value.  Refer to the \refmodule{warnings} module for | 
 |   more information on the warnings framework. | 
 | \end{datadesc} | 
 |  | 
 | \begin{datadesc}{winver} | 
 |   The version number used to form registry keys on Windows platforms. | 
 |   This is stored as string resource 1000 in the Python DLL.  The value | 
 |   is normally the first three characters of \constant{version}.  It is | 
 |   provided in the \module{sys} module for informational purposes; | 
 |   modifying this value has no effect on the registry keys used by | 
 |   Python. | 
 |   Availability: Windows. | 
 | \end{datadesc} | 
 |  | 
 |  | 
 | \begin{seealso} | 
 |   \seemodule{site} | 
 |     {This describes how to use .pth files to extend \code{sys.path}.} | 
 | \end{seealso} |