[Checkins] SVN: zope.deprecation/trunk/ Improved reSTX rendering.
Tres Seaver
tseaver at palladion.com
Sat Jul 4 13:11:22 EDT 2009
Log message for revision 101556:
Improved reSTX rendering.
Changed:
U zope.deprecation/trunk/CHANGES.txt
U zope.deprecation/trunk/README.txt
U zope.deprecation/trunk/setup.py
U zope.deprecation/trunk/src/zope/deprecation/README.txt
-=-
Modified: zope.deprecation/trunk/CHANGES.txt
===================================================================
--- zope.deprecation/trunk/CHANGES.txt 2009-07-04 16:46:15 UTC (rev 101555)
+++ zope.deprecation/trunk/CHANGES.txt 2009-07-04 17:11:22 UTC (rev 101556)
@@ -1,6 +1,7 @@
-Releases
-********
+``zope.deprecation`` Changelog
+##############################
+
==================
3.4.1 (unreleased)
==================
@@ -10,41 +11,46 @@
Added support to bootstrap on Jython.
-Fix zope.deprecation.warn() to make the signature identical to
-warnings.warn() and to check for .pyc and .pyo files.
+Fix ``zope.deprecation.warn()`` to make the signature identical to
+``warnings.warn()`` and to check for .pyc and .pyo files.
+
==================
3.4.0 (2007/07/19)
==================
Release 3.4 final, corresponding to Zope 3.4.
+
==================
3.3.0 (2007/02/18)
==================
-Corresponds to the verison of the zope.deprecation package shipped as part of
-the Zope 3.3.0 release.
+Corresponds to the verison of the ``zope.deprecation`` package shipped as
+part of the Zope 3.3.0 release.
+
====================
3.2.0.2 (2006/04/15)
====================
-Fix packaging bug: 'package_dir' must be a *relative* path.
+Fix packaging bug: ``package_dir`` must be a *relative* path.
+
==================
3.2.0 (2006/01/05)
==================
-Corresponds to the verison of the zope.deprecation package shipped as part of
-the Zope 3.2.0 release.
+Corresponds to the verison of the ``zope.deprecation`` package shipped as part
+of the Zope 3.2.0 release.
-Refactored to eliminate dependency on 'zope.proxy'. This was an especially
-bad dependency due to the required C exension in 'zope.proxy'.
+Refactored to eliminate dependency on ``zope.proxy``. This was an especially
+bad dependency due to the required C exension in ``zope.proxy``.
+
==================
3.1.0 (2005/10/03)
==================
-Corresponds to the verison of the zope.deprecation package shipped as part of
-the Zope 3.1.0 release.
+Corresponds to the verison of the ``zope.deprecation`` package shipped as
+part of the Zope 3.1.0 release.
Modified: zope.deprecation/trunk/README.txt
===================================================================
--- zope.deprecation/trunk/README.txt 2009-07-04 16:46:15 UTC (rev 101555)
+++ zope.deprecation/trunk/README.txt 2009-07-04 17:11:22 UTC (rev 101556)
@@ -1,9 +1,8 @@
-****************
-zope.deprecation
-****************
+``zope.deprecation`` Package
+############################
When we started working on Zope 3.1, we noticed that the hardest part of the
development process was to ensure backward-compatibility and correctly mark
deprecated modules, classes, functions, methods and properties. This package
-provides a simple function called 'deprecated(names, reason)' to deprecate the
-previously mentioned Python objects.
+provides a simple function called ``deprecated(names, reason)`` to deprecate
+the previously mentioned Python objects.
Modified: zope.deprecation/trunk/setup.py
===================================================================
--- zope.deprecation/trunk/setup.py 2009-07-04 16:46:15 UTC (rev 101555)
+++ zope.deprecation/trunk/setup.py 2009-07-04 17:11:22 UTC (rev 101556)
@@ -34,15 +34,12 @@
long_description=(
read('README.txt')
+ '\n' +
- read('CHANGES.txt')
- + '\n' +
- 'Detailed Documentation\n'
- '**********************\n'
- + '\n' +
read('src', 'zope', 'deprecation', 'README.txt')
+ '\n' +
+ read('CHANGES.txt')
+ + '\n' +
'Download\n'
- '**********************\n'
+ '########\n'
),
package_dir = {'': 'src'},
Modified: zope.deprecation/trunk/src/zope/deprecation/README.txt
===================================================================
--- zope.deprecation/trunk/src/zope/deprecation/README.txt 2009-07-04 16:46:15 UTC (rev 101555)
+++ zope.deprecation/trunk/src/zope/deprecation/README.txt 2009-07-04 17:11:22 UTC (rev 101556)
@@ -2,18 +2,12 @@
Deprecation API
===============
-When we started working on Zope 3.1, we noticed that the hardest part of the
-development process was to ensure backward-compatibility and correctly mark
-deprecated modules, classes, functions, methods and properties. This module
-provides a simple function called `deprecated(names, reason)` to deprecate the
-previously mentioned Python objects.
-
Deprecating objects inside a module
-----------------------------------
Let's start with a demonstration of deprecating any name inside a module. To
demonstrate the functionality, I have placed the following code inside the
-`tests.py` file of this package:
+``tests.py`` file of this package::
from zope.deprecation import deprecated
demo1 = 1
@@ -25,7 +19,7 @@
demo3 = 3
deprecated('demo3', 'demo3 is no more.')
-The first argument to the `deprecated()` function is a list of names that
+The first argument to the ``deprecated()`` function is a list of names that
should be declared deprecated. If the first argument is a string, it is
interpreted as one name. The second argument is the reason the particular name
has been deprecated. It is good practice to also list the version in which the
@@ -292,8 +286,9 @@
--------------------------------------------
In some cases it is desireable to turn off the deprecation warnings for a
-short time. To support such a feature, the `zope.deprecation` package provides
-an attribute called `__show__`. One can ask for its status by calling it:
+short time. To support such a feature, the ``zope.deprecation`` package
+provides an attribute called ``__show__``. One can ask for its status by
+calling it:
>>> from zope.deprecation import __show__
>>> __show__()
@@ -321,7 +316,7 @@
>>> foo.blah
1
-Now, you can also nest several turn-offs, so that calling `off()` multiple
+Now, you can also nest several turn-offs, so that calling ``off()`` multiple
times is meaningful:
>>> __show__.stack
@@ -343,7 +338,7 @@
>>> __show__()
True
-You can also reset `__show__` to `True`:
+You can also reset ``__show__`` to ``True``:
>>> __show__.off()
>>> __show__.off()
@@ -354,7 +349,7 @@
>>> __show__()
True
-Finally, you cannot call `on()` without having called `off()` before:
+Finally, you cannot call ``on()`` without having called ``off()`` before:
>>> __show__.on()
Traceback (most recent call last):
More information about the Checkins
mailing list