mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-09-27 02:39:58 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 13

Branch merge

Browse source
This commit is contained in:
Éric Araujo 2011-05-29 18:08:34 +02:00
commit c739066914
8 changed files with 113 additions and 109 deletions
Download patch file Download diff file Expand all files Collapse all files

156
Doc/distutils/apiref.rst
View file

@ -21,7 +21,7 @@ setup script). Indirectly provides the :class:`distutils.dist.Distribution` and
.. function:: setup(arguments)
The basic do-everything function that does most everything you could ever ask
for from a Distutils method. See XXXXX
for from a Distutils method.
The setup function takes a large number of arguments. These are laid out in the
following table.
@ -147,11 +147,11 @@ setup script). Indirectly provides the :class:`distutils.dist.Distribution` and
In addition, the :mod:`distutils.core` module exposed a number of classes that
live elsewhere.
* :class:`Extension` from :mod:`distutils.extension`
* :class:`~distutils.extension.Extension` from :mod:`distutils.extension`
* :class:`Command` from :mod:`distutils.cmd`
* :class:`~distutils.cmd.Command` from :mod:`distutils.cmd`
* :class:`Distribution` from :mod:`distutils.dist`
* :class:`~distutils.dist.Distribution` from :mod:`distutils.dist`
A short description of each of these follows, but see the relevant module for
the full reference.
@ -1678,8 +1678,8 @@ lines, and joining lines with backslashes.
===================================================================
.. module:: distutils.cmd
:synopsis: This module provides the abstract base class Command. This class is subclassed
by the modules in the distutils.command subpackage.
:synopsis: This module provides the abstract base class Command. This class
is subclassed by the modules in the distutils.command subpackage.
This module supplies the abstract base class :class:`Command`.
@ -1689,20 +1689,84 @@ This module supplies the abstract base class :class:`Command`.
Abstract base class for defining command classes, the "worker bees" of the
Distutils. A useful analogy for command classes is to think of them as
subroutines with local variables called *options*. The options are declared in
:meth:`initialize_options` and defined (given their final values) in
:meth:`finalize_options`, both of which must be defined by every command class.
The distinction between the two is necessary because option values might come
from the outside world (command line, config file, ...), and any options
dependent on other options must be computed after these outside influences have
been processed --- hence :meth:`finalize_options`. The body of the subroutine,
where it does all its work based on the values of its options, is the
:meth:`run` method, which must also be implemented by every command class.
subroutines with local variables called *options*. The options are declared
in :meth:`initialize_options` and defined (given their final values) in
:meth:`finalize_options`, both of which must be defined by every command
class. The distinction between the two is necessary because option values
might come from the outside world (command line, config file, ...), and any
options dependent on other options must be computed after these outside
influences have been processed --- hence :meth:`finalize_options`. The body
of the subroutine, where it does all its work based on the values of its
options, is the :meth:`run` method, which must also be implemented by every
command class.
The class constructor takes a single argument *dist*, a :class:`Distribution`
The class constructor takes a single argument *dist*, a :class:`Distribution`
instance.
Creating a new Distutils command
================================
This section outlines the steps to create a new Distutils command.
A new command lives in a module in the :mod:`distutils.command` package. There
is a sample template in that directory called :file:`command_template`. Copy
this file to a new module with the same name as the new command you're
implementing. This module should implement a class with the same name as the
module (and the command). So, for instance, to create the command
``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
:file:`command_template` to :file:`distutils/command/peel_banana.py`, then edit
it so that it's implementing the class :class:`peel_banana`, a subclass of
:class:`distutils.cmd.Command`.
Subclasses of :class:`Command` must define the following methods.
.. method:: Command.initialize_options()
Set default values for all the options that this command supports. Note that
these defaults may be overridden by other commands, by the setup script, by
config files, or by the command-line. Thus, this is not the place to code
dependencies between options; generally, :meth:`initialize_options`
implementations are just a bunch of ``self.foo = None`` assignments.
.. method:: Command.finalize_options()
Set final values for all the options that this command supports. This is
always called as late as possible, ie. after any option assignments from the
command-line or from other commands have been done. Thus, this is the place
to to code option dependencies: if *foo* depends on *bar*, then it is safe to
set *foo* from *bar* as long as *foo* still has the same value it was
assigned in :meth:`initialize_options`.
.. method:: Command.run()
A command's raison d'etre: carry out the action it exists to perform, controlled
by the options initialized in :meth:`initialize_options`, customized by other
commands, the setup script, the command-line, and config files, and finalized in
:meth:`finalize_options`. All terminal output and filesystem interaction should
be done by :meth:`run`.
.. attribute:: Command.sub_commands
*sub_commands* formalizes the notion of a "family" of commands,
e.g. ``install`` as the parent with sub-commands ``install_lib``,
``install_headers``, etc. The parent of a family of commands defines
*sub_commands* as a class attribute; it's a list of 2-tuples ``(command_name,
predicate)``, with *command_name* a string and *predicate* a function, a
string or ``None``. *predicate* is a method of the parent command that
determines whether the corresponding command is applicable in the current
situation. (E.g. ``install_headers`` is only applicable if we have any C
header files to install.) If *predicate* is ``None``, that command is always
applicable.
*sub_commands* is usually defined at the *end* of a class, because
predicates can be methods of the class, so they must already have been
defined. The canonical example is the :command:`install` command.
:mod:`distutils.command` --- Individual Distutils commands
==========================================================
@ -1954,63 +2018,3 @@ For example, it verifies that all required meta-data are provided as
the arguments passed to the :func:`setup` function.
.. % todo
Creating a new Distutils command
================================
This section outlines the steps to create a new Distutils command.
A new command lives in a module in the :mod:`distutils.command` package. There
is a sample template in that directory called :file:`command_template`. Copy
this file to a new module with the same name as the new command you're
implementing. This module should implement a class with the same name as the
module (and the command). So, for instance, to create the command
``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
:file:`command_template` to :file:`distutils/command/peel_banana.py`, then edit
it so that it's implementing the class :class:`peel_banana`, a subclass of
:class:`distutils.cmd.Command`.
Subclasses of :class:`Command` must define the following methods.
.. method:: Command.initialize_options()
Set default values for all the options that this command supports. Note that
these defaults may be overridden by other commands, by the setup script, by
config files, or by the command-line. Thus, this is not the place to code
dependencies between options; generally, :meth:`initialize_options`
implementations are just a bunch of ``self.foo = None`` assignments.
.. method:: Command.finalize_options()
Set final values for all the options that this command supports. This is
always called as late as possible, ie. after any option assignments from the
command-line or from other commands have been done. Thus, this is the place
to to code option dependencies: if *foo* depends on *bar*, then it is safe to
set *foo* from *bar* as long as *foo* still has the same value it was
assigned in :meth:`initialize_options`.
.. method:: Command.run()
A command's raison d'etre: carry out the action it exists to perform, controlled
by the options initialized in :meth:`initialize_options`, customized by other
commands, the setup script, the command-line, and config files, and finalized in
:meth:`finalize_options`. All terminal output and filesystem interaction should
be done by :meth:`run`.
*sub_commands* formalizes the notion of a "family" of commands, eg. ``install``
as the parent with sub-commands ``install_lib``, ``install_headers``, etc. The
parent of a family of commands defines *sub_commands* as a class attribute; it's
a list of 2-tuples ``(command_name, predicate)``, with *command_name* a string
and *predicate* a function, a string or None. *predicate* is a method of
the parent command that determines whether the corresponding command is
applicable in the current situation. (Eg. we ``install_headers`` is only
applicable if we have any C header files to install.) If *predicate* is None,
that command is always applicable.
*sub_commands* is usually defined at the \*end\* of a class, because predicates
can be methods of the class, so they must already have been defined. The
canonical example is the :command:`install` command.

4
Doc/distutils/extending.rst
View file

@ -15,8 +15,8 @@ want to modify existing commands; many simply add a few file extensions that
should be copied into packages in addition to :file:`.py` files as a
convenience.
Most distutils command implementations are subclasses of the :class:`Command`
class from :mod:`distutils.cmd`. New commands may directly inherit from
Most distutils command implementations are subclasses of the
:class:`distutils.cmd.Command` class. New commands may directly inherit from
:class:`Command`, while replacements often derive from :class:`Command`
indirectly, directly subclassing the command they are replacing. Commands are
required to derive from :class:`Command`.

2
Doc/glossary.rst
View file

@ -247,7 +247,7 @@ Glossary
processing, remembering the location execution state (including local
variables and pending try-statements). When the generator resumes, it
picks-up where it left-off (in contrast to functions which start fresh on
every invocation.
every invocation).
.. index:: single: generator expression

32
Doc/library/crypt.rst
View file

@ -29,6 +29,8 @@ this module.
Hashing Methods
---------------
.. versionadded:: 3.3
The :mod:`crypt` module defines the list of hashing methods (not all methods
are available on all platforms):
@ -37,33 +39,26 @@ are available on all platforms):
A Modular Crypt Format method with 16 character salt and 86 character
hash. This is the strongest method.
.. versionadded:: 3.3
.. data:: METHOD_SHA256
Another Modular Crypt Format method with 16 character salt and 43
character hash.
.. versionadded:: 3.3
.. data:: METHOD_MD5
Another Modular Crypt Format method with 8 character salt and 22
character hash.
.. versionadded:: 3.3
.. data:: METHOD_CRYPT
The traditional method with a 2 character salt and 13 characters of
hash. This is the weakest method.
.. versionadded:: 3.3
Module Attributes
-----------------
.. versionadded:: 3.3
.. attribute:: methods
@ -71,8 +66,6 @@ Module Attributes
``crypt.METHOD_*`` objects. This list is sorted from strongest to
weakest, and is guaranteed to have at least ``crypt.METHOD_CRYPT``.
.. versionadded:: 3.3
Module Functions
----------------
@ -108,9 +101,8 @@ The :mod:`crypt` module defines the following functions:
different sizes in the *salt*, it is recommended to use the full crypted
password as salt when checking for a password.
.. versionchanged:: 3.3
Before version 3.3, *salt* must be specified as a string and cannot
accept ``crypt.METHOD_*`` values (which don't exist anyway).
.. versionchanged:: 3.3
Accept ``crypt.METHOD_*`` values in addition to strings for *salt*.
.. function:: mksalt(method=None)
@ -124,25 +116,27 @@ The :mod:`crypt` module defines the following functions:
16 random characters from the set ``[./a-zA-Z0-9]``, suitable for
passing as the *salt* argument to :func:`crypt`.
.. versionadded:: 3.3
.. versionadded:: 3.3
Examples
--------
A simple example illustrating typical use::
import crypt, getpass, pwd
import pwd
import crypt
import getpass
def login():
username = input('Python login:')
username = input('Python login: ')
cryptedpasswd = pwd.getpwnam(username)[1]
if cryptedpasswd:
if cryptedpasswd == 'x' or cryptedpasswd == '*':
raise "Sorry, currently no support for shadow passwords"
raise ValueError('no support for shadow passwords')
cleartext = getpass.getpass()
return crypt.crypt(cleartext, cryptedpasswd) == cryptedpasswd
else:
return 1
return True
To generate a hash of a password using the strongest available method and
check it against the original::
@ -151,4 +145,4 @@ check it against the original::
hashed = crypt.crypt(plaintext)
if hashed != crypt.crypt(plaintext, hashed):
raise "Hashed version doesn't validate against original"
raise ValueError("hashed version doesn't validate against original")

2
Doc/library/functions.rst
View file

@ -580,7 +580,7 @@ are always available. They are listed here in alphabetical order.
Two objects with non-overlapping lifetimes may have the same :func:`id`
value.
.. impl-detail:: This is the address of the object.
.. impl-detail:: This is the address of the object in memory.
.. function:: input([prompt])

15
Lib/distutils/tests/test_build_py.py
View file

@ -57,12 +57,15 @@ class BuildPyTestCase(support.TempdirManager,
self.assertEqual(len(cmd.get_outputs()), 3)
pkgdest = os.path.join(destination, "pkg")
files = os.listdir(pkgdest)
self.assertTrue("__init__.py" in files)
if not sys.dont_write_bytecode:
self.assertTrue("__init__.pyc" in files)
self.assertTrue("README.txt" in files)
self.assertIn("__init__.py", files)
self.assertIn("README.txt", files)
# XXX even with -O, distutils writes pyc, not pyo; bug?
if sys.dont_write_bytecode:
self.assertNotIn("__init__.pyc", files)
else:
self.assertIn("__init__.pyc", files)
def test_empty_package_dir (self):
def test_empty_package_dir(self):
# See SF 1668596/1720897.
cwd = os.getcwd()
@ -110,7 +113,7 @@ class BuildPyTestCase(support.TempdirManager,
finally:
sys.dont_write_bytecode = old_dont_write_bytecode
self.assertTrue('byte-compiling is disabled' in self.logs[0][1])
self.assertIn('byte-compiling is disabled', self.logs[0][1])
def test_suite():
return unittest.makeSuite(BuildPyTestCase)

2
Lib/packaging/tests/test_command_build_ext.py
View file

@ -265,7 +265,7 @@ class BuildExtTestCase(support.TempdirManager,
def test_get_outputs(self):
tmp_dir = self.mkdtemp()
c_file = os.path.join(tmp_dir, 'foo.c')
self.write_file(c_file, 'void PyInit_foo(void) {};\n')
self.write_file(c_file, 'void PyInit_foo(void) {}\n')
ext = Extension('foo', [c_file], optional=False)
dist = Distribution({'name': 'xx',
'ext_modules': [ext]})

9
Lib/packaging/tests/test_command_build_py.py
View file

@ -61,9 +61,12 @@ class BuildPyTestCase(support.TempdirManager,
pkgdest = os.path.join(destination, "pkg")
files = os.listdir(pkgdest)
self.assertIn("__init__.py", files)
if not sys.dont_write_bytecode:
self.assertIn("__init__.pyc", files)
self.assertIn("README.txt", files)
# XXX even with -O, distutils writes pyc, not pyo; bug?
if sys.dont_write_bytecode:
self.assertNotIn("__init__.pyc", files)
else:
self.assertIn("__init__.pyc", files)
def test_empty_package_dir(self):
# See SF 1668596/1720897.
@ -93,7 +96,7 @@ class BuildPyTestCase(support.TempdirManager,
try:
dist.run_commands()
except PackagingFileError as e:
except PackagingFileError:
self.fail("failed package_data test when package_dir is ''")
finally:
# Restore state.