Added Python (Thanks to Beholder) - it fails to build properly using my build system,
so there's a precompiled binary included, with a hack in Android.mk to make it work on NDK r4b
This commit is contained in:
545
project/jni/python/src/Doc/using/cmdline.rst
Normal file
545
project/jni/python/src/Doc/using/cmdline.rst
Normal file
@@ -0,0 +1,545 @@
|
||||
.. highlightlang:: none
|
||||
|
||||
.. _using-on-general:
|
||||
|
||||
Command line and environment
|
||||
============================
|
||||
|
||||
The CPython interpreter scans the command line and the environment for various
|
||||
settings.
|
||||
|
||||
.. note::
|
||||
|
||||
Other implementations' command line schemes may differ. See
|
||||
:ref:`implementations` for further resources.
|
||||
|
||||
|
||||
.. _using-on-cmdline:
|
||||
|
||||
Command line
|
||||
------------
|
||||
|
||||
When invoking Python, you may specify any of these options::
|
||||
|
||||
python [-dEiOQsStuUvxX3?] [-c command | -m module-name | script | - ] [args]
|
||||
|
||||
The most common use case is, of course, a simple invocation of a script::
|
||||
|
||||
python myscript.py
|
||||
|
||||
|
||||
.. _using-on-interface-options:
|
||||
|
||||
Interface options
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The interpreter interface resembles that of the UNIX shell, but provides some
|
||||
additional methods of invocation:
|
||||
|
||||
* When called with standard input connected to a tty device, it prompts for
|
||||
commands and executes them until an EOF (an end-of-file character, you can
|
||||
produce that with *Ctrl-D* on UNIX or *Ctrl-Z, Enter* on Windows) is read.
|
||||
* When called with a file name argument or with a file as standard input, it
|
||||
reads and executes a script from that file.
|
||||
* When called with a directory name argument, it reads and executes an
|
||||
appropriately named script from that directory.
|
||||
* When called with ``-c command``, it executes the Python statement(s) given as
|
||||
*command*. Here *command* may contain multiple statements separated by
|
||||
newlines. Leading whitespace is significant in Python statements!
|
||||
* When called with ``-m module-name``, the given module is located on the
|
||||
Python module path and executed as a script.
|
||||
|
||||
In non-interactive mode, the entire input is parsed before it is executed.
|
||||
|
||||
An interface option terminates the list of options consumed by the interpreter,
|
||||
all consecutive arguments will end up in :data:`sys.argv` -- note that the first
|
||||
element, subscript zero (``sys.argv[0]``), is a string reflecting the program's
|
||||
source.
|
||||
|
||||
.. cmdoption:: -c <command>
|
||||
|
||||
Execute the Python code in *command*. *command* can be one ore more
|
||||
statements separated by newlines, with significant leading whitespace as in
|
||||
normal module code.
|
||||
|
||||
If this option is given, the first element of :data:`sys.argv` will be
|
||||
``"-c"`` and the current directory will be added to the start of
|
||||
:data:`sys.path` (allowing modules in that directory to be imported as top
|
||||
level modules).
|
||||
|
||||
|
||||
.. cmdoption:: -m <module-name>
|
||||
|
||||
Search :data:`sys.path` for the named module and execute its contents as
|
||||
the :mod:`__main__` module.
|
||||
|
||||
Since the argument is a *module* name, you must not give a file extension
|
||||
(``.py``). The ``module-name`` should be a valid Python module name, but
|
||||
the implementation may not always enforce this (e.g. it may allow you to
|
||||
use a name that includes a hyphen).
|
||||
|
||||
.. note::
|
||||
|
||||
This option cannot be used with builtin modules and extension modules
|
||||
written in C, since they do not have Python module files. However, it
|
||||
can still be used for precompiled modules, even if the original source
|
||||
file is not available.
|
||||
|
||||
If this option is given, the first element of :data:`sys.argv` will be the
|
||||
full path to the module file. As with the :option:`-c` option, the current
|
||||
directory will be added to the start of :data:`sys.path`.
|
||||
|
||||
Many standard library modules contain code that is invoked on their execution
|
||||
as a script. An example is the :mod:`timeit` module::
|
||||
|
||||
python -mtimeit -s 'setup here' 'benchmarked code here'
|
||||
python -mtimeit -h # for details
|
||||
|
||||
.. seealso::
|
||||
:func:`runpy.run_module`
|
||||
The actual implementation of this feature.
|
||||
|
||||
:pep:`338` -- Executing modules as scripts
|
||||
|
||||
.. versionadded:: 2.4
|
||||
|
||||
.. versionchanged:: 2.5
|
||||
The named module can now be located inside a package.
|
||||
|
||||
|
||||
.. describe:: -
|
||||
|
||||
Read commands from standard input (:data:`sys.stdin`). If standard input is
|
||||
a terminal, :option:`-i` is implied.
|
||||
|
||||
If this option is given, the first element of :data:`sys.argv` will be
|
||||
``"-"`` and the current directory will be added to the start of
|
||||
:data:`sys.path`.
|
||||
|
||||
|
||||
.. describe:: <script>
|
||||
|
||||
Execute the Python code contained in *script*, which must be a filesystem
|
||||
path (absolute or relative) referring to either a Python file, a directory
|
||||
containing a ``__main__.py`` file, or a zipfile containing a
|
||||
``__main__.py`` file.
|
||||
|
||||
If this option is given, the first element of :data:`sys.argv` will be the
|
||||
script name as given on the command line.
|
||||
|
||||
If the script name refers directly to a Python file, the directory
|
||||
containing that file is added to the start of :data:`sys.path`, and the
|
||||
file is executed as the :mod:`__main__` module.
|
||||
|
||||
If the script name refers to a directory or zipfile, the script name is
|
||||
added to the start of :data:`sys.path` and the ``__main__.py`` file in
|
||||
that location is executed as the :mod:`__main__` module.
|
||||
|
||||
.. versionchanged:: 2.5
|
||||
Directories and zipfiles containing a ``__main__.py`` file at the top
|
||||
level are now considered valid Python scripts.
|
||||
|
||||
If no interface option is given, :option:`-i` is implied, ``sys.argv[0]`` is
|
||||
an empty string (``""``) and the current directory will be added to the
|
||||
start of :data:`sys.path`.
|
||||
|
||||
.. seealso:: :ref:`tut-invoking`
|
||||
|
||||
|
||||
Generic options
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
.. cmdoption:: -?
|
||||
-h
|
||||
--help
|
||||
|
||||
Print a short description of all command line options.
|
||||
|
||||
.. versionchanged:: 2.5
|
||||
The ``--help`` variant.
|
||||
|
||||
|
||||
.. cmdoption:: -V
|
||||
--version
|
||||
|
||||
Print the Python version number and exit. Example output could be::
|
||||
|
||||
Python 2.5.1
|
||||
|
||||
.. versionchanged:: 2.5
|
||||
The ``--version`` variant.
|
||||
|
||||
|
||||
Miscellaneous options
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. cmdoption:: -B
|
||||
|
||||
If given, Python won't try to write ``.pyc`` or ``.pyo`` files on the
|
||||
import of source modules. See also :envvar:`PYTHONDONTWRITEBYTECODE`.
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
|
||||
.. cmdoption:: -d
|
||||
|
||||
Turn on parser debugging output (for wizards only, depending on compilation
|
||||
options). See also :envvar:`PYTHONDEBUG`.
|
||||
|
||||
|
||||
.. cmdoption:: -E
|
||||
|
||||
Ignore all :envvar:`PYTHON*` environment variables, e.g.
|
||||
:envvar:`PYTHONPATH` and :envvar:`PYTHONHOME`, that might be set.
|
||||
|
||||
.. versionadded:: 2.2
|
||||
|
||||
|
||||
.. cmdoption:: -i
|
||||
|
||||
When a script is passed as first argument or the :option:`-c` option is used,
|
||||
enter interactive mode after executing the script or the command, even when
|
||||
:data:`sys.stdin` does not appear to be a terminal. The
|
||||
:envvar:`PYTHONSTARTUP` file is not read.
|
||||
|
||||
This can be useful to inspect global variables or a stack trace when a script
|
||||
raises an exception. See also :envvar:`PYTHONINSPECT`.
|
||||
|
||||
|
||||
.. cmdoption:: -O
|
||||
|
||||
Turn on basic optimizations. This changes the filename extension for
|
||||
compiled (:term:`bytecode`) files from ``.pyc`` to ``.pyo``. See also
|
||||
:envvar:`PYTHONOPTIMIZE`.
|
||||
|
||||
|
||||
.. cmdoption:: -OO
|
||||
|
||||
Discard docstrings in addition to the :option:`-O` optimizations.
|
||||
|
||||
|
||||
.. cmdoption:: -Q <arg>
|
||||
|
||||
Division control. The argument must be one of the following:
|
||||
|
||||
``old``
|
||||
division of int/int and long/long return an int or long (*default*)
|
||||
``new``
|
||||
new division semantics, i.e. division of int/int and long/long returns a
|
||||
float
|
||||
``warn``
|
||||
old division semantics with a warning for int/int and long/long
|
||||
``warnall``
|
||||
old division semantics with a warning for all uses of the division operator
|
||||
|
||||
.. seealso::
|
||||
:file:`Tools/scripts/fixdiv.py`
|
||||
for a use of ``warnall``
|
||||
|
||||
:pep:`238` -- Changing the division operator
|
||||
|
||||
|
||||
.. cmdoption:: -s
|
||||
|
||||
Don't add user site directory to sys.path
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`370` -- Per user site-packages directory
|
||||
|
||||
|
||||
.. cmdoption:: -S
|
||||
|
||||
Disable the import of the module :mod:`site` and the site-dependent
|
||||
manipulations of :data:`sys.path` that it entails.
|
||||
|
||||
|
||||
.. cmdoption:: -t
|
||||
|
||||
Issue a warning when a source file mixes tabs and spaces for indentation in a
|
||||
way that makes it depend on the worth of a tab expressed in spaces. Issue an
|
||||
error when the option is given twice (:option:`-tt`).
|
||||
|
||||
|
||||
.. cmdoption:: -u
|
||||
|
||||
Force stdin, stdout and stderr to be totally unbuffered. On systems where it
|
||||
matters, also put stdin, stdout and stderr in binary mode.
|
||||
|
||||
Note that there is internal buffering in :meth:`file.readlines` and
|
||||
:ref:`bltin-file-objects` (``for line in sys.stdin``) which is not influenced
|
||||
by this option. To work around this, you will want to use
|
||||
:meth:`file.readline` inside a ``while 1:`` loop.
|
||||
|
||||
See also :envvar:`PYTHONUNBUFFERED`.
|
||||
|
||||
|
||||
.. XXX should the -U option be documented?
|
||||
|
||||
.. cmdoption:: -v
|
||||
|
||||
Print a message each time a module is initialized, showing the place
|
||||
(filename or built-in module) from which it is loaded. When given twice
|
||||
(:option:`-vv`), print a message for each file that is checked for when
|
||||
searching for a module. Also provides information on module cleanup at exit.
|
||||
See also :envvar:`PYTHONVERBOSE`.
|
||||
|
||||
|
||||
.. cmdoption:: -W arg
|
||||
|
||||
Warning control. Python's warning machinery by default prints warning
|
||||
messages to :data:`sys.stderr`. A typical warning message has the following
|
||||
form::
|
||||
|
||||
file:line: category: message
|
||||
|
||||
By default, each warning is printed once for each source line where it
|
||||
occurs. This option controls how often warnings are printed.
|
||||
|
||||
Multiple :option:`-W` options may be given; when a warning matches more than
|
||||
one option, the action for the last matching option is performed. Invalid
|
||||
:option:`-W` options are ignored (though, a warning message is printed about
|
||||
invalid options when the first warning is issued).
|
||||
|
||||
Warnings can also be controlled from within a Python program using the
|
||||
:mod:`warnings` module.
|
||||
|
||||
The simplest form of argument is one of the following action strings (or a
|
||||
unique abbreviation):
|
||||
|
||||
``ignore``
|
||||
Ignore all warnings.
|
||||
``default``
|
||||
Explicitly request the default behavior (printing each warning once per
|
||||
source line).
|
||||
``all``
|
||||
Print a warning each time it occurs (this may generate many messages if a
|
||||
warning is triggered repeatedly for the same source line, such as inside a
|
||||
loop).
|
||||
``module``
|
||||
Print each warning only only the first time it occurs in each module.
|
||||
``once``
|
||||
Print each warning only the first time it occurs in the program.
|
||||
``error``
|
||||
Raise an exception instead of printing a warning message.
|
||||
|
||||
The full form of argument is::
|
||||
|
||||
action:message:category:module:line
|
||||
|
||||
Here, *action* is as explained above but only applies to messages that match
|
||||
the remaining fields. Empty fields match all values; trailing empty fields
|
||||
may be omitted. The *message* field matches the start of the warning message
|
||||
printed; this match is case-insensitive. The *category* field matches the
|
||||
warning category. This must be a class name; the match test whether the
|
||||
actual warning category of the message is a subclass of the specified warning
|
||||
category. The full class name must be given. The *module* field matches the
|
||||
(fully-qualified) module name; this match is case-sensitive. The *line*
|
||||
field matches the line number, where zero matches all line numbers and is
|
||||
thus equivalent to an omitted line number.
|
||||
|
||||
.. seealso::
|
||||
:mod:`warnings` -- the warnings module
|
||||
|
||||
:pep:`230` -- Warning framework
|
||||
|
||||
|
||||
.. cmdoption:: -x
|
||||
|
||||
Skip the first line of the source, allowing use of non-Unix forms of
|
||||
``#!cmd``. This is intended for a DOS specific hack only.
|
||||
|
||||
.. warning:: The line numbers in error messages will be off by one!
|
||||
|
||||
|
||||
.. cmdoption:: -3
|
||||
|
||||
Warn about Python 3.x incompatibilities which cannot be fixed trivially by
|
||||
:ref:`2to3 <2to3-reference>`. Among these are:
|
||||
|
||||
* :meth:`dict.has_key`
|
||||
* :func:`apply`
|
||||
* :func:`callable`
|
||||
* :func:`coerce`
|
||||
* :func:`execfile`
|
||||
* :func:`reduce`
|
||||
* :func:`reload`
|
||||
|
||||
Using these will emit a :exc:`DeprecationWarning`.
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
|
||||
|
||||
.. _using-on-envvars:
|
||||
|
||||
Environment variables
|
||||
---------------------
|
||||
|
||||
These environment variables influence Python's behavior.
|
||||
|
||||
.. envvar:: PYTHONHOME
|
||||
|
||||
Change the location of the standard Python libraries. By default, the
|
||||
libraries are searched in :file:`{prefix}/lib/python{version}` and
|
||||
:file:`{exec_prefix}/lib/python{version}`, where :file:`{prefix}` and
|
||||
:file:`{exec_prefix}` are installation-dependent directories, both defaulting
|
||||
to :file:`/usr/local`.
|
||||
|
||||
When :envvar:`PYTHONHOME` is set to a single directory, its value replaces
|
||||
both :file:`{prefix}` and :file:`{exec_prefix}`. To specify different values
|
||||
for these, set :envvar:`PYTHONHOME` to :file:`{prefix}:{exec_prefix}`.
|
||||
|
||||
|
||||
.. envvar:: PYTHONPATH
|
||||
|
||||
Augment the default search path for module files. The format is the same as
|
||||
the shell's :envvar:`PATH`: one or more directory pathnames separated by
|
||||
:data:`os.pathsep` (e.g. colons on Unix or semicolons on Windows).
|
||||
Non-existent directories are silently ignored.
|
||||
|
||||
In addition to normal directories, individual :envvar:`PYTHONPATH` entries
|
||||
may refer to zipfiles containing pure Python modules (in either source or
|
||||
compiled form). Extension modules cannot be imported from zipfiles.
|
||||
|
||||
The default search path is installation dependent, but generally begins with
|
||||
:file:`{prefix}/lib/python{version}` (see :envvar:`PYTHONHOME` above). It
|
||||
is *always* appended to :envvar:`PYTHONPATH`.
|
||||
|
||||
An additional directory will be inserted in the search path in front of
|
||||
:envvar:`PYTHONPATH` as described above under
|
||||
:ref:`using-on-interface-options`. The search path can be manipulated from
|
||||
within a Python program as the variable :data:`sys.path`.
|
||||
|
||||
|
||||
.. envvar:: PYTHONSTARTUP
|
||||
|
||||
If this is the name of a readable file, the Python commands in that file are
|
||||
executed before the first prompt is displayed in interactive mode. The file
|
||||
is executed in the same namespace where interactive commands are executed so
|
||||
that objects defined or imported in it can be used without qualification in
|
||||
the interactive session. You can also change the prompts :data:`sys.ps1` and
|
||||
:data:`sys.ps2` in this file.
|
||||
|
||||
|
||||
.. envvar:: PYTHONY2K
|
||||
|
||||
Set this to a non-empty string to cause the :mod:`time` module to require
|
||||
dates specified as strings to include 4-digit years, otherwise 2-digit years
|
||||
are converted based on rules described in the :mod:`time` module
|
||||
documentation.
|
||||
|
||||
|
||||
.. envvar:: PYTHONOPTIMIZE
|
||||
|
||||
If this is set to a non-empty string it is equivalent to specifying the
|
||||
:option:`-O` option. If set to an integer, it is equivalent to specifying
|
||||
:option:`-O` multiple times.
|
||||
|
||||
|
||||
.. envvar:: PYTHONDEBUG
|
||||
|
||||
If this is set to a non-empty string it is equivalent to specifying the
|
||||
:option:`-d` option. If set to an integer, it is equivalent to specifying
|
||||
:option:`-d` multiple times.
|
||||
|
||||
|
||||
.. envvar:: PYTHONINSPECT
|
||||
|
||||
If this is set to a non-empty string it is equivalent to specifying the
|
||||
:option:`-i` option.
|
||||
|
||||
This variable can also be modified by Python code using :data:`os.environ`
|
||||
to force inspect mode on program termination.
|
||||
|
||||
|
||||
.. envvar:: PYTHONUNBUFFERED
|
||||
|
||||
If this is set to a non-empty string it is equivalent to specifying the
|
||||
:option:`-u` option.
|
||||
|
||||
|
||||
.. envvar:: PYTHONVERBOSE
|
||||
|
||||
If this is set to a non-empty string it is equivalent to specifying the
|
||||
:option:`-v` option. If set to an integer, it is equivalent to specifying
|
||||
:option:`-v` multiple times.
|
||||
|
||||
|
||||
.. envvar:: PYTHONCASEOK
|
||||
|
||||
If this is set, Python ignores case in :keyword:`import` statements. This
|
||||
only works on Windows.
|
||||
|
||||
|
||||
.. envvar:: PYTHONDONTWRITEBYTECODE
|
||||
|
||||
If this is set, Python won't try to write ``.pyc`` or ``.pyo`` files on the
|
||||
import of source modules.
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
.. envvar:: PYTHONIOENCODING
|
||||
|
||||
Overrides the encoding used for stdin/stdout/stderr, in the syntax
|
||||
``encodingname:errorhandler``. The ``:errorhandler`` part is optional and
|
||||
has the same meaning as in :func:`str.encode`.
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
|
||||
.. envvar:: PYTHONNOUSERSITE
|
||||
|
||||
If this is set, Python won't add the user site directory to sys.path
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`370` -- Per user site-packages directory
|
||||
|
||||
|
||||
.. envvar:: PYTHONUSERBASE
|
||||
|
||||
Sets the base directory for the user site directory
|
||||
|
||||
.. versionadded:: 2.6
|
||||
|
||||
.. seealso::
|
||||
|
||||
:pep:`370` -- Per user site-packages directory
|
||||
|
||||
|
||||
.. envvar:: PYTHONEXECUTABLE
|
||||
|
||||
If this environment variable is set, ``sys.argv[0]`` will be set to its
|
||||
value instead of the value got through the C runtime. Only works on
|
||||
Mac OS X.
|
||||
|
||||
|
||||
Debug-mode variables
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Setting these variables only has an effect in a debug build of Python, that is,
|
||||
if Python was configured with the :option:`--with-pydebug` build option.
|
||||
|
||||
.. envvar:: PYTHONTHREADDEBUG
|
||||
|
||||
If set, Python will print threading debug info.
|
||||
|
||||
.. versionchanged:: 2.6
|
||||
Previously, this variable was called ``THREADDEBUG``.
|
||||
|
||||
.. envvar:: PYTHONDUMPREFS
|
||||
|
||||
If set, Python will dump objects and reference counts still alive after
|
||||
shutting down the interpreter.
|
||||
|
||||
|
||||
.. envvar:: PYTHONMALLOCSTATS
|
||||
|
||||
If set, Python will print memory allocation statistics every time a new
|
||||
object arena is created, and on shutdown.
|
||||
|
||||
20
project/jni/python/src/Doc/using/index.rst
Normal file
20
project/jni/python/src/Doc/using/index.rst
Normal file
@@ -0,0 +1,20 @@
|
||||
.. _using-index:
|
||||
|
||||
################
|
||||
Using Python
|
||||
################
|
||||
|
||||
|
||||
This part of the documentation is devoted to general information on the setup
|
||||
of the Python environment on different platform, the invocation of the
|
||||
interpreter and things that make working with Python easier.
|
||||
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
|
||||
cmdline.rst
|
||||
unix.rst
|
||||
windows.rst
|
||||
mac.rst
|
||||
|
||||
205
project/jni/python/src/Doc/using/mac.rst
Normal file
205
project/jni/python/src/Doc/using/mac.rst
Normal file
@@ -0,0 +1,205 @@
|
||||
|
||||
.. _using-on-mac:
|
||||
|
||||
***************************
|
||||
Using Python on a Macintosh
|
||||
***************************
|
||||
|
||||
:Author: Bob Savage <bobsavage@mac.com>
|
||||
|
||||
|
||||
Python on a Macintosh running Mac OS X is in principle very similar to Python on
|
||||
any other Unix platform, but there are a number of additional features such as
|
||||
the IDE and the Package Manager that are worth pointing out.
|
||||
|
||||
The Mac-specific modules are documented in :ref:`mac-specific-services`.
|
||||
|
||||
Python on Mac OS 9 or earlier can be quite different from Python on Unix or
|
||||
Windows, but is beyond the scope of this manual, as that platform is no longer
|
||||
supported, starting with Python 2.4. See http://www.cwi.nl/~jack/macpython for
|
||||
installers for the latest 2.3 release for Mac OS 9 and related documentation.
|
||||
|
||||
|
||||
.. _getting-osx:
|
||||
|
||||
Getting and Installing MacPython
|
||||
================================
|
||||
|
||||
Mac OS X 10.5 comes with Python 2.5.1 pre-installed by Apple. If you wish, you
|
||||
are invited to install the most recent version of Python from the Python website
|
||||
(http://www.python.org). A current "universal binary" build of Python, which
|
||||
runs natively on the Mac's new Intel and legacy PPC CPU's, is available there.
|
||||
|
||||
What you get after installing is a number of things:
|
||||
|
||||
* A :file:`MacPython 2.5` folder in your :file:`Applications` folder. In here
|
||||
you find IDLE, the development environment that is a standard part of official
|
||||
Python distributions; PythonLauncher, which handles double-clicking Python
|
||||
scripts from the Finder; and the "Build Applet" tool, which allows you to
|
||||
package Python scripts as standalone applications on your system.
|
||||
|
||||
* A framework :file:`/Library/Frameworks/Python.framework`, which includes the
|
||||
Python executable and libraries. The installer adds this location to your shell
|
||||
path. To uninstall MacPython, you can simply remove these three things. A
|
||||
symlink to the Python executable is placed in /usr/local/bin/.
|
||||
|
||||
The Apple-provided build of Python is installed in
|
||||
:file:`/System/Library/Frameworks/Python.framework` and :file:`/usr/bin/python`,
|
||||
respectively. You should never modify or delete these, as they are
|
||||
Apple-controlled and are used by Apple- or third-party software. Remember that
|
||||
if you choose to install a newer Python version from python.org, you will have
|
||||
two different but functional Python installations on your computer, so it will
|
||||
be important that your paths and usages are consistent with what you want to do.
|
||||
|
||||
IDLE includes a help menu that allows you to access Python documentation. If you
|
||||
are completely new to Python you should start reading the tutorial introduction
|
||||
in that document.
|
||||
|
||||
If you are familiar with Python on other Unix platforms you should read the
|
||||
section on running Python scripts from the Unix shell.
|
||||
|
||||
|
||||
How to run a Python script
|
||||
--------------------------
|
||||
|
||||
Your best way to get started with Python on Mac OS X is through the IDLE
|
||||
integrated development environment, see section :ref:`ide` and use the Help menu
|
||||
when the IDE is running.
|
||||
|
||||
If you want to run Python scripts from the Terminal window command line or from
|
||||
the Finder you first need an editor to create your script. Mac OS X comes with a
|
||||
number of standard Unix command line editors, :program:`vim` and
|
||||
:program:`emacs` among them. If you want a more Mac-like editor,
|
||||
:program:`BBEdit` or :program:`TextWrangler` from Bare Bones Software (see
|
||||
http://www.barebones.com/products/bbedit/index.shtml) are good choices, as is
|
||||
:program:`TextMate` (see http://macromates.com/). Other editors include
|
||||
:program:`Gvim` (http://macvim.org) and :program:`Aquamacs`
|
||||
(http://aquamacs.org).
|
||||
|
||||
To run your script from the Terminal window you must make sure that
|
||||
:file:`/usr/local/bin` is in your shell search path.
|
||||
|
||||
To run your script from the Finder you have two options:
|
||||
|
||||
* Drag it to :program:`PythonLauncher`
|
||||
|
||||
* Select :program:`PythonLauncher` as the default application to open your
|
||||
script (or any .py script) through the finder Info window and double-click it.
|
||||
:program:`PythonLauncher` has various preferences to control how your script is
|
||||
launched. Option-dragging allows you to change these for one invocation, or use
|
||||
its Preferences menu to change things globally.
|
||||
|
||||
|
||||
.. _osx-gui-scripts:
|
||||
|
||||
Running scripts with a GUI
|
||||
--------------------------
|
||||
|
||||
With older versions of Python, there is one Mac OS X quirk that you need to be
|
||||
aware of: programs that talk to the Aqua window manager (in other words,
|
||||
anything that has a GUI) need to be run in a special way. Use :program:`pythonw`
|
||||
instead of :program:`python` to start such scripts.
|
||||
|
||||
With Python 2.5, you can use either :program:`python` or :program:`pythonw`.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Python on OS X honors all standard Unix environment variables such as
|
||||
:envvar:`PYTHONPATH`, but setting these variables for programs started from the
|
||||
Finder is non-standard as the Finder does not read your :file:`.profile` or
|
||||
:file:`.cshrc` at startup. You need to create a file :file:`~
|
||||
/.MacOSX/environment.plist`. See Apple's Technical Document QA1067 for details.
|
||||
|
||||
For more information on installation Python packages in MacPython, see section
|
||||
:ref:`mac-package-manager`.
|
||||
|
||||
|
||||
.. _ide:
|
||||
|
||||
The IDE
|
||||
=======
|
||||
|
||||
MacPython ships with the standard IDLE development environment. A good
|
||||
introduction to using IDLE can be found at http://hkn.eecs.berkeley.edu/
|
||||
dyoo/python/idle_intro/index.html.
|
||||
|
||||
|
||||
.. _mac-package-manager:
|
||||
|
||||
Installing Additional Python Packages
|
||||
=====================================
|
||||
|
||||
There are several methods to install additional Python packages:
|
||||
|
||||
* http://pythonmac.org/packages/ contains selected compiled packages for Python
|
||||
2.5, 2.4, and 2.3.
|
||||
|
||||
* Packages can be installed via the standard Python distutils mode (``python
|
||||
setup.py install``).
|
||||
|
||||
* Many packages can also be installed via the :program:`setuptools` extension.
|
||||
|
||||
|
||||
GUI Programming on the Mac
|
||||
==========================
|
||||
|
||||
There are several options for building GUI applications on the Mac with Python.
|
||||
|
||||
*PyObjC* is a Python binding to Apple's Objective-C/Cocoa framework, which is
|
||||
the foundation of most modern Mac development. Information on PyObjC is
|
||||
available from http://pyobjc.sourceforge.net.
|
||||
|
||||
The standard Python GUI toolkit is :mod:`Tkinter`, based on the cross-platform
|
||||
Tk toolkit (http://www.tcl.tk). An Aqua-native version of Tk is bundled with OS
|
||||
X by Apple, and the latest version can be downloaded and installed from
|
||||
http://www.activestate.com; it can also be built from source.
|
||||
|
||||
*wxPython* is another popular cross-platform GUI toolkit that runs natively on
|
||||
Mac OS X. Packages and documentation are available from http://www.wxpython.org.
|
||||
|
||||
*PyQt* is another popular cross-platform GUI toolkit that runs natively on Mac
|
||||
OS X. More information can be found at
|
||||
http://www.riverbankcomputing.co.uk/pyqt/.
|
||||
|
||||
|
||||
Distributing Python Applications on the Mac
|
||||
===========================================
|
||||
|
||||
The "Build Applet" tool that is placed in the MacPython 2.5 folder is fine for
|
||||
packaging small Python scripts on your own machine to run as a standard Mac
|
||||
application. This tool, however, is not robust enough to distribute Python
|
||||
applications to other users.
|
||||
|
||||
The standard tool for deploying standalone Python applications on the Mac is
|
||||
:program:`py2app`. More information on installing and using py2app can be found
|
||||
at http://undefined.org/python/#py2app.
|
||||
|
||||
|
||||
Application Scripting
|
||||
=====================
|
||||
|
||||
Python can also be used to script other Mac applications via Apple's Open
|
||||
Scripting Architecture (OSA); see http://appscript.sourceforge.net. Appscript is
|
||||
a high-level, user-friendly Apple event bridge that allows you to control
|
||||
scriptable Mac OS X applications using ordinary Python scripts. Appscript makes
|
||||
Python a serious alternative to Apple's own *AppleScript* language for
|
||||
automating your Mac. A related package, *PyOSA*, is an OSA language component
|
||||
for the Python scripting language, allowing Python code to be executed by any
|
||||
OSA-enabled application (Script Editor, Mail, iTunes, etc.). PyOSA makes Python
|
||||
a full peer to AppleScript.
|
||||
|
||||
|
||||
Other Resources
|
||||
===============
|
||||
|
||||
The MacPython mailing list is an excellent support resource for Python users and
|
||||
developers on the Mac:
|
||||
|
||||
http://www.python.org/community/sigs/current/pythonmac-sig/
|
||||
|
||||
Another useful resource is the MacPython wiki:
|
||||
|
||||
http://wiki.python.org/moin/MacPython
|
||||
|
||||
151
project/jni/python/src/Doc/using/unix.rst
Normal file
151
project/jni/python/src/Doc/using/unix.rst
Normal file
@@ -0,0 +1,151 @@
|
||||
.. highlightlang:: none
|
||||
|
||||
.. _using-on-unix:
|
||||
|
||||
********************************
|
||||
Using Python on Unix platforms
|
||||
********************************
|
||||
|
||||
.. sectionauthor:: Shriphani Palakodety
|
||||
|
||||
|
||||
Getting and installing the latest version of Python
|
||||
===================================================
|
||||
|
||||
On Linux
|
||||
--------
|
||||
|
||||
Python comes preinstalled on most Linux distributions, and is available as a
|
||||
package on all others. However there are certain features you might want to use
|
||||
that are not available on your distro's package. You can easily compile the
|
||||
latest version of Python from source.
|
||||
|
||||
In the event that Python doesn't come preinstalled and isn't in the repositories as
|
||||
well, you can easily make packages for your own distro. Have a look at the
|
||||
following links:
|
||||
|
||||
.. seealso::
|
||||
|
||||
http://www.linux.com/articles/60383
|
||||
for Debian users
|
||||
http://linuxmafia.com/pub/linux/suse-linux-internals/chapter35.html
|
||||
for OpenSuse users
|
||||
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-creating-rpms.html
|
||||
for Fedora users
|
||||
http://www.slackbook.org/html/package-management-making-packages.html
|
||||
for Slackware users
|
||||
|
||||
|
||||
On FreeBSD and OpenBSD
|
||||
----------------------
|
||||
|
||||
* FreeBSD users, to add the package use::
|
||||
|
||||
pkg_add -r python
|
||||
|
||||
* OpenBSD users use::
|
||||
|
||||
pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/<insert your architecture here>/python-<version>.tgz
|
||||
|
||||
For example i386 users get the 2.5.1 version of Python using::
|
||||
|
||||
pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/4.2/packages/i386/python-2.5.1p2.tgz
|
||||
|
||||
|
||||
On OpenSolaris
|
||||
--------------
|
||||
|
||||
To install the newest Python versions on OpenSolaris, install blastwave
|
||||
(http://www.blastwave.org/howto.html) and type "pkg_get -i python" at the
|
||||
prompt.
|
||||
|
||||
|
||||
Building Python
|
||||
===============
|
||||
|
||||
If you want to compile CPython yourself, first thing you should do is get the
|
||||
`source <http://python.org/download/source/>`_. You can download either the
|
||||
latest release's source or just grab a fresh `checkout
|
||||
<http://www.python.org/dev/faq/#how-do-i-get-a-checkout-of-the-repository-read-only-and-read-write>`_.
|
||||
|
||||
The build process consists the usual ::
|
||||
|
||||
./configure
|
||||
make
|
||||
make install
|
||||
|
||||
invocations. Configuration options and caveats for specific Unix platforms are
|
||||
extensively documented in the :file:`README` file in the root of the Python
|
||||
source tree.
|
||||
|
||||
.. warning::
|
||||
|
||||
``make install`` can overwrite or masquerade the :file:`python` binary.
|
||||
``make altinstall`` is therefore recommended instead of ``make install``
|
||||
since it only installs :file:`{exec_prefix}/bin/python{version}`.
|
||||
|
||||
|
||||
Python-related paths and files
|
||||
==============================
|
||||
|
||||
These are subject to difference depending on local installation conventions;
|
||||
:envvar:`prefix` (``${prefix}``) and :envvar:`exec_prefix` (``${exec_prefix}``)
|
||||
are installation-dependent and should be interpreted as for GNU software; they
|
||||
may be the same.
|
||||
|
||||
For example, on most Linux systems, the default for both is :file:`/usr`.
|
||||
|
||||
+-----------------------------------------------+------------------------------------------+
|
||||
| File/directory | Meaning |
|
||||
+===============================================+==========================================+
|
||||
| :file:`{exec_prefix}/bin/python` | Recommended location of the interpreter. |
|
||||
+-----------------------------------------------+------------------------------------------+
|
||||
| :file:`{prefix}/lib/python{version}`, | Recommended locations of the directories |
|
||||
| :file:`{exec_prefix}/lib/python{version}` | containing the standard modules. |
|
||||
+-----------------------------------------------+------------------------------------------+
|
||||
| :file:`{prefix}/include/python{version}`, | Recommended locations of the directories |
|
||||
| :file:`{exec_prefix}/include/python{version}` | containing the include files needed for |
|
||||
| | developing Python extensions and |
|
||||
| | embedding the interpreter. |
|
||||
+-----------------------------------------------+------------------------------------------+
|
||||
| :file:`~/.pythonrc.py` | User-specific initialization file loaded |
|
||||
| | by the user module; not used by default |
|
||||
| | or by most applications. |
|
||||
+-----------------------------------------------+------------------------------------------+
|
||||
|
||||
|
||||
Miscellaneous
|
||||
=============
|
||||
|
||||
To easily use Python scripts on Unix, you need to make them executable,
|
||||
e.g. with ::
|
||||
|
||||
$ chmod +x script
|
||||
|
||||
and put an appropriate Shebang line at the top of the script. A good choice is
|
||||
usually ::
|
||||
|
||||
#!/usr/bin/env python
|
||||
|
||||
which searches for the Python interpreter in the whole :envvar:`PATH`. However,
|
||||
some Unices may not have the :program:`env` command, so you may need to hardcode
|
||||
``/usr/bin/python`` as the interpreter path.
|
||||
|
||||
To use shell commands in your python scripts, look at the :mod:`subprocess` module.
|
||||
|
||||
|
||||
Editors
|
||||
=======
|
||||
|
||||
Vim and Emacs are excellent editors which support Python very well. For more
|
||||
information on how to code in python in these editors, look at:
|
||||
|
||||
* http://www.vim.org/scripts/script.php?script_id=790
|
||||
* http://sourceforge.net/projects/python-mode
|
||||
|
||||
Geany is an excellent IDE with support for a lot of languages. For more
|
||||
information, read: http://geany.uvena.de/
|
||||
|
||||
Komodo edit is another extremely good IDE. It also has support for a lot of
|
||||
languages. For more information, read:
|
||||
http://www.activestate.com/store/productdetail.aspx?prdGuid=20f4ed15-6684-4118-a78b-d37ff4058c5f
|
||||
320
project/jni/python/src/Doc/using/windows.rst
Normal file
320
project/jni/python/src/Doc/using/windows.rst
Normal file
@@ -0,0 +1,320 @@
|
||||
.. highlightlang:: none
|
||||
|
||||
.. _using-on-windows:
|
||||
|
||||
*************************
|
||||
Using Python on Windows
|
||||
*************************
|
||||
|
||||
.. sectionauthor:: Robert Lehmann <lehmannro@gmail.com>
|
||||
|
||||
This document aims to give an overview of Windows-specific behaviour you should
|
||||
know about when using Python on Microsoft Windows.
|
||||
|
||||
|
||||
Installing Python
|
||||
=================
|
||||
|
||||
Unlike most Unix systems and services, Windows does not require Python natively
|
||||
and thus does not pre-install a version of Python. However, the CPython team
|
||||
has compiled Windows installers (MSI packages) with every `release
|
||||
<http://www.python.org/download/releases/>`_ for many years.
|
||||
|
||||
With ongoing development of Python, some platforms that used to be supported
|
||||
earlier are no longer supported (due to the lack of users or developers).
|
||||
Check :pep:`11` for details on all unsupported platforms.
|
||||
|
||||
* DOS and Windows 3.x are deprecated since Python 2.0 and code specific to these
|
||||
systems was removed in Python 2.1.
|
||||
* Up to 2.5, Python was still compatible with Windows 95, 98 and ME (but already
|
||||
raised a deprecation warning on installation). For Python 2.6 (and all
|
||||
following releases), this support was dropped and new releases are just
|
||||
expected to work on the Windows NT family.
|
||||
* `Windows CE <http://pythonce.sourceforge.net/>`_ is still supported.
|
||||
* The `Cygwin <http://cygwin.com/>`_ installer offers to install the `Python
|
||||
interpreter <http://cygwin.com/packages/python>`_ as well; it is located under
|
||||
"Interpreters." (cf. `Cygwin package source
|
||||
<ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/
|
||||
release/python>`_, `Maintainer releases
|
||||
<http://www.tishler.net/jason/software/python/>`_)
|
||||
|
||||
See `Python for Windows (and DOS) <http://www.python.org/download/windows/>`_
|
||||
for detailed information about platforms with precompiled installers.
|
||||
|
||||
.. seealso::
|
||||
|
||||
`Python on XP <http://www.richarddooling.com/index.php/2006/03/14/python-on-xp-7-minutes-to-hello-world/>`_
|
||||
"7 Minutes to "Hello World!""
|
||||
by Richard Dooling, 2006
|
||||
|
||||
`Installing on Windows <http://diveintopython.org/installing_python/windows.html>`_
|
||||
in "`Dive into Python: Python from novice to pro
|
||||
<http://diveintopython.org/index.html>`_"
|
||||
by Mark Pilgrim, 2004,
|
||||
ISBN 1-59059-356-1
|
||||
|
||||
`For Windows users <http://swaroopch.com/text/Byte_of_Python:Installing_Python#For_Windows_users>`_
|
||||
in "Installing Python"
|
||||
in "`A Byte of Python <http://www.byteofpython.info>`_"
|
||||
by Swaroop C H, 2003
|
||||
|
||||
|
||||
Alternative bundles
|
||||
===================
|
||||
|
||||
Besides the standard CPython distribution, there are modified packages including
|
||||
additional functionality. The following is a list of popular versions and their
|
||||
key features:
|
||||
|
||||
`ActivePython <http://www.activestate.com/Products/activepython/>`_
|
||||
Installer with multi-platform compatibility, documentation, PyWin32
|
||||
|
||||
`Python Enthought Edition <http://code.enthought.com/enthon/>`_
|
||||
Popular modules (such as PyWin32) with their respective documentation, tool
|
||||
suite for building extensible python applications
|
||||
|
||||
Notice that these packages are likely to install *older* versions of Python.
|
||||
|
||||
|
||||
|
||||
Configuring Python
|
||||
==================
|
||||
|
||||
In order to run Python flawlessly, you might have to change certain environment
|
||||
settings in Windows.
|
||||
|
||||
|
||||
Excursus: Setting environment variables
|
||||
---------------------------------------
|
||||
|
||||
Windows has a built-in dialog for changing environment variables (following
|
||||
guide applies to XP classical view): Right-click the icon for your machine
|
||||
(usually located on your Desktop and called "My Computer") and choose
|
||||
:menuselection:`Properties` there. Then, open the :guilabel:`Advanced` tab
|
||||
and click the :guilabel:`Environment Variables` button.
|
||||
|
||||
In short, your path is:
|
||||
|
||||
:menuselection:`My Computer
|
||||
--> Properties
|
||||
--> Advanced
|
||||
--> Environment Variables`
|
||||
|
||||
In this dialog, you can add or modify User and System variables. To change
|
||||
System variables, you need non-restricted access to your machine
|
||||
(i.e. Administrator rights).
|
||||
|
||||
Another way of adding variables to your environment is using the :command:`set`
|
||||
command::
|
||||
|
||||
set PYTHONPATH=%PYTHONPATH%;C:\My_python_lib
|
||||
|
||||
To make this setting permanent, you could add the corresponding command line to
|
||||
your :file:`autoexec.bat`. :program:`msconfig` is a graphical interface to this
|
||||
file.
|
||||
|
||||
Viewing environment variables can also be done more straight-forward: The
|
||||
command prompt will expand strings wrapped into percent signs automatically::
|
||||
|
||||
echo %PATH%
|
||||
|
||||
Consult :command:`set /?` for details on this behaviour.
|
||||
|
||||
.. seealso::
|
||||
|
||||
http://support.microsoft.com/kb/100843
|
||||
Environment variables in Windows NT
|
||||
|
||||
http://support.microsoft.com/kb/310519
|
||||
How To Manage Environment Variables in Windows XP
|
||||
|
||||
http://www.chem.gla.ac.uk/~louis/software/faq/q1.html
|
||||
Setting Environment variables, Louis J. Farrugia
|
||||
|
||||
|
||||
Finding the Python executable
|
||||
-----------------------------
|
||||
|
||||
Besides using the automatically created start menu entry for the Python
|
||||
interpreter, you might want to start Python in the DOS prompt. To make this
|
||||
work, you need to set your :envvar:`%PATH%` environment variable to include the
|
||||
directory of your Python distribution, delimited by a semicolon from other
|
||||
entries. An example variable could look like this (assuming the first two
|
||||
entries are Windows' default)::
|
||||
|
||||
C:\WINDOWS\system32;C:\WINDOWS;C:\Python25
|
||||
|
||||
Typing :command:`python` on your command prompt will now fire up the Python
|
||||
interpreter. Thus, you can also execute your scripts with command line options,
|
||||
see :ref:`using-on-cmdline` documentation.
|
||||
|
||||
|
||||
Finding modules
|
||||
---------------
|
||||
|
||||
Python usually stores its library (and thereby your site-packages folder) in the
|
||||
installation directory. So, if you had installed Python to
|
||||
:file:`C:\\Python\\`, the default library would reside in
|
||||
:file:`C:\\Python\\Lib\\` and third-party modules should be stored in
|
||||
:file:`C:\\Python\\Lib\\site-packages\\`.
|
||||
|
||||
.. `` this fixes syntax highlighting errors in some editors due to the \\ hackery
|
||||
|
||||
You can add folders to your search path to make Python's import mechanism search
|
||||
in these directories as well. Use :envvar:`PYTHONPATH`, as described in
|
||||
:ref:`using-on-envvars`, to modify :data:`sys.path`. On Windows, paths are
|
||||
separated by semicolons, though, to distinguish them from drive identifiers
|
||||
(:file:`C:\\` etc.).
|
||||
|
||||
.. ``
|
||||
|
||||
Modifying the module search path can also be done through the Windows registry:
|
||||
Edit
|
||||
:file:`HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\{version}\\PythonPath\\`,
|
||||
as described above for the environment variable :envvar:`%PYTHONPATH%`. A
|
||||
convenient registry editor is :program:`regedit` (start it by typing "regedit"
|
||||
into :menuselection:`Start --> Run`).
|
||||
|
||||
|
||||
Executing scripts
|
||||
-----------------
|
||||
|
||||
Python scripts (files with the extension ``.py``) will be executed by
|
||||
:program:`python.exe` by default. This executable opens a terminal, which stays
|
||||
open even if the program uses a GUI. If you do not want this to happen, use the
|
||||
extension ``.pyw`` which will cause the script to be executed by
|
||||
:program:`pythonw.exe` by default (both executables are located in the top-level
|
||||
of your Python installation directory). This suppresses the terminal window on
|
||||
startup.
|
||||
|
||||
You can also make all ``.py`` scripts execute with :program:`pythonw.exe`,
|
||||
setting this through the usual facilities, for example (might require
|
||||
administrative rights):
|
||||
|
||||
#. Launch a command prompt.
|
||||
#. Associate the correct file group with ``.py`` scripts::
|
||||
|
||||
assoc .py=Python.File
|
||||
|
||||
#. Redirect all Python files to the new executable::
|
||||
|
||||
ftype Python.File=C:\Path\to\pythonw.exe "%1" %*
|
||||
|
||||
|
||||
Additional modules
|
||||
==================
|
||||
|
||||
Even though Python aims to be portable among all platforms, there are features
|
||||
that are unique to Windows. A couple of modules, both in the standard library
|
||||
and external, and snippets exist to use these features.
|
||||
|
||||
The Windows-specific standard modules are documented in
|
||||
:ref:`mswin-specific-services`.
|
||||
|
||||
|
||||
PyWin32
|
||||
-------
|
||||
|
||||
The `PyWin32 <http://python.net/crew/mhammond/win32/>`_ module by Mark Hammond
|
||||
is a collection of modules for advanced Windows-specific support. This includes
|
||||
utilities for:
|
||||
|
||||
* `Component Object Model <http://www.microsoft.com/com/>`_ (COM)
|
||||
* Win32 API calls
|
||||
* Registry
|
||||
* Event log
|
||||
* `Microsoft Foundation Classes <http://msdn.microsoft.com/library/
|
||||
en-us/vclib/html/_mfc_Class_Library_Reference_Introduction.asp>`_ (MFC)
|
||||
user interfaces
|
||||
|
||||
`PythonWin <http://web.archive.org/web/20060524042422/
|
||||
http://www.python.org/windows/pythonwin/>`_ is a sample MFC application
|
||||
shipped with PyWin32. It is an embeddable IDE with a built-in debugger.
|
||||
|
||||
.. seealso::
|
||||
|
||||
`Win32 How Do I...? <http://timgolden.me.uk/python/win32_how_do_i.html>`_
|
||||
by Tim Golden
|
||||
|
||||
`Python and COM <http://www.boddie.org.uk/python/COM.html>`_
|
||||
by David and Paul Boddie
|
||||
|
||||
|
||||
Py2exe
|
||||
------
|
||||
|
||||
`Py2exe <http://www.py2exe.org/>`_ is a :mod:`distutils` extension (see
|
||||
:ref:`extending-distutils`) which wraps Python scripts into executable Windows
|
||||
programs (:file:`{*}.exe` files). When you have done this, you can distribute
|
||||
your application without requiring your users to install Python.
|
||||
|
||||
|
||||
WConio
|
||||
------
|
||||
|
||||
Since Python's advanced terminal handling layer, :mod:`curses`, is restricted to
|
||||
Unix-like systems, there is a library exclusive to Windows as well: Windows
|
||||
Console I/O for Python.
|
||||
|
||||
`WConio <http://newcenturycomputers.net/projects/wconio.html>`_ is a wrapper for
|
||||
Turbo-C's :file:`CONIO.H`, used to create text user interfaces.
|
||||
|
||||
|
||||
|
||||
Compiling Python on Windows
|
||||
===========================
|
||||
|
||||
If you want to compile CPython yourself, first thing you should do is get the
|
||||
`source <http://python.org/download/source/>`_. You can download either the
|
||||
latest release's source or just grab a fresh `checkout
|
||||
<http://www.python.org/dev/faq/#how-do-i-get-a-checkout-of-the-repository-read-only-and-read-write>`_.
|
||||
|
||||
For Microsoft Visual C++, which is the compiler with which official Python
|
||||
releases are built, the source tree contains solutions/project files. View the
|
||||
:file:`readme.txt` in their respective directories:
|
||||
|
||||
+--------------------+--------------+-----------------------+
|
||||
| Directory | MSVC version | Visual Studio version |
|
||||
+====================+==============+=======================+
|
||||
| :file:`PC/VC6/` | 6.0 | 97 |
|
||||
+--------------------+--------------+-----------------------+
|
||||
| :file:`PC/VS7.1/` | 7.1 | 2003 |
|
||||
+--------------------+--------------+-----------------------+
|
||||
| :file:`PC/VS8.0/` | 8.0 | 2005 |
|
||||
+--------------------+--------------+-----------------------+
|
||||
| :file:`PCbuild/` | 9.0 | 2008 |
|
||||
+--------------------+--------------+-----------------------+
|
||||
|
||||
Note that not all of these build directories are fully supported. Read the
|
||||
release notes to see which compiler version the official releases for your
|
||||
version are built with.
|
||||
|
||||
Check :file:`PC/readme.txt` for general information on the build process.
|
||||
|
||||
|
||||
For extension modules, consult :ref:`building-on-windows`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
`Python + Windows + distutils + SWIG + gcc MinGW <http://sebsauvage.net/python/mingw.html>`_
|
||||
or "Creating Python extensions in C/C++ with SWIG and compiling them with
|
||||
MinGW gcc under Windows" or "Installing Python extension with distutils
|
||||
and without Microsoft Visual C++" by Sébastien Sauvage, 2003
|
||||
|
||||
`MingW -- Python extensions <http://www.mingw.org/MinGWiki/index.php/Python%20extensions>`_
|
||||
by Trent Apted et al, 2007
|
||||
|
||||
|
||||
Other resources
|
||||
===============
|
||||
|
||||
.. seealso::
|
||||
|
||||
`Python Programming On Win32 <http://www.oreilly.com/catalog/pythonwin32/>`_
|
||||
"Help for Windows Programmers"
|
||||
by Mark Hammond and Andy Robinson, O'Reilly Media, 2000,
|
||||
ISBN 1-56592-621-8
|
||||
|
||||
`A Python for Windows Tutorial <http://www.imladris.com/Scripts/PythonForWindows.html>`_
|
||||
by Amanda Birmingham, 2004
|
||||
|
||||
Reference in New Issue
Block a user