reSTify PEP 285 (#366)
This commit is contained in:
Huang Huang
Guido van Rossum
parent
27d218f1bb
commit
b596c6abe3
342
pep-0285.txt
342
pep-0285.txt
|
|
@ -5,36 +5,39 @@ Last-Modified: $Date$
|
|||
Author: guido@python.org (Guido van Rossum)
|
||||
Status: Final
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 8-Mar-2002
|
||||
Python-Version: 2.3
|
||||
Post-History: 8-Mar-2002, 30-Mar-2002, 3-Apr-2002
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This PEP proposes the introduction of a new built-in type, bool,
|
||||
with two constants, False and True. The bool type would be a
|
||||
straightforward subtype (in C) of the int type, and the values
|
||||
False and True would behave like 0 and 1 in most respects (for
|
||||
example, False==0 and True==1 would be true) except repr() and
|
||||
str(). All built-in operations that conceptually return a Boolean
|
||||
result will be changed to return False or True instead of 0 or 1;
|
||||
for example, comparisons, the "not" operator, and predicates like
|
||||
isinstance().
|
||||
This PEP proposes the introduction of a new built-in type, bool,
|
||||
with two constants, ``False`` and ``True``. The bool type would be a
|
||||
straightforward subtype (in C) of the int type, and the values
|
||||
``False`` and ``True`` would behave like 0 and 1 in most respects (for
|
||||
example, ``False==0`` and ``True==1`` would be true) except ``repr()`` and
|
||||
``str()``. All built-in operations that conceptually return a Boolean
|
||||
result will be changed to return ``False`` or ``True`` instead of 0 or 1;
|
||||
for example, comparisons, the "not" operator, and predicates like
|
||||
``isinstance()``.
|
||||
|
||||
|
||||
Review
|
||||
======
|
||||
|
||||
I've collected enough feedback to last me a lifetime, so I declare
|
||||
the review period officially OVER. I had Chinese food today; my
|
||||
fortune cookie said "Strong and bitter words indicate a weak
|
||||
cause." It reminded me of some of the posts against this
|
||||
PEP... :-)
|
||||
I've collected enough feedback to last me a lifetime, so I declare
|
||||
the review period officially OVER. I had Chinese food today; my
|
||||
fortune cookie said "Strong and bitter words indicate a weak
|
||||
cause." It reminded me of some of the posts against this
|
||||
PEP... :-)
|
||||
|
||||
Anyway, here are my BDFL pronouncements. (Executive summary: I'm
|
||||
not changing a thing; all variants are rejected.)
|
||||
Anyway, here are my BDFL pronouncements. (Executive summary: I'm
|
||||
not changing a thing; all variants are rejected.)
|
||||
|
||||
1) Should this PEP be accepted?
|
||||
1) Should this PEP be accepted?
|
||||
|
||||
=> Yes.
|
||||
|
||||
|
|
@ -46,15 +49,15 @@ Review
|
|||
More about that below too. I think this is not a sufficient
|
||||
reason to reject the PEP.
|
||||
|
||||
2) Should str(True) return "True" or "1"? "1" might reduce
|
||||
2) Should ``str(True)`` return "True" or "1"? "1" might reduce
|
||||
backwards compatibility problems, but looks strange.
|
||||
(repr(True) would always return "True".)
|
||||
(``repr(True)`` would always return "True".)
|
||||
|
||||
=> "True".
|
||||
|
||||
Almost all reviewers agree with this.
|
||||
|
||||
3) Should the constants be called 'True' and 'False' (similar to
|
||||
3) Should the constants be called 'True' and 'False' (similar to
|
||||
None) or 'true' and 'false' (as in C++, Java and C99)?
|
||||
|
||||
=> True and False.
|
||||
|
|
@ -62,7 +65,7 @@ Review
|
|||
Most reviewers agree that consistency within Python is more
|
||||
important than consistency with other languages.
|
||||
|
||||
4) Should we strive to eliminate non-Boolean operations on bools
|
||||
4) Should we strive to eliminate non-Boolean operations on bools
|
||||
in the future, through suitable warnings, so that for example
|
||||
True+1 would eventually (in Python 3000) be illegal?
|
||||
|
||||
|
|
@ -73,19 +76,19 @@ Review
|
|||
all, but most reviewers agree with me that bools should always
|
||||
allow arithmetic operations.
|
||||
|
||||
5) Should operator.truth(x) return an int or a bool?
|
||||
5) Should ``operator.truth(x)`` return an int or a bool?
|
||||
|
||||
=> bool.
|
||||
|
||||
Tim Peters believes it should return an int, but almost all
|
||||
other reviewers agree that it should return a bool. My
|
||||
rationale: operator.truth() exists to force a Boolean context
|
||||
on its argument (it calls the C API PyObject_IsTrue()).
|
||||
rationale: ``operator.truth()`` exists to force a Boolean context
|
||||
on its argument (it calls the C API ``PyObject_IsTrue())``.
|
||||
Whether the outcome is reported as int or bool is secondary; if
|
||||
bool exists there's no reason not to use it. (Under the PEP,
|
||||
operator.truth() now becomes an alias for bool(); that's fine.)
|
||||
``operator.truth()`` now becomes an alias for ``bool()``; that's fine.)
|
||||
|
||||
6) Should bool inherit from int?
|
||||
6) Should bool inherit from int?
|
||||
|
||||
=> Yes.
|
||||
|
||||
|
|
@ -93,7 +96,7 @@ Review
|
|||
separate integer type that knows how to perform mixed-mode
|
||||
arithmetic. However, inheriting bool from int eases the
|
||||
implementation enormously (in part since all C code that calls
|
||||
PyInt_Check() will continue to work -- this returns true for
|
||||
``PyInt_Check()`` will continue to work -- this returns true for
|
||||
subclasses of int). Also, I believe this is right in terms of
|
||||
substitutability: code that requires an int can be fed a bool
|
||||
and it will behave the same as 0 or 1. Code that requires a
|
||||
|
|
@ -101,7 +104,7 @@ Review
|
|||
is 0, but both 3 and 4 are true when considered as truth
|
||||
values.
|
||||
|
||||
7) Should the name 'bool' be changed?
|
||||
7) Should the name 'bool' be changed?
|
||||
|
||||
=> No.
|
||||
|
||||
|
|
@ -121,7 +124,7 @@ Review
|
|||
container is interpreted as a truth value, an empty container
|
||||
is considered false and a non-empty one is considered true."
|
||||
|
||||
8) Should we strive to require that Boolean operations (like "if",
|
||||
8) Should we strive to require that Boolean operations (like "if",
|
||||
"and", "not") have a bool as an argument in the future, so that
|
||||
for example "if []:" would become illegal and would have to be
|
||||
written as "if bool([]):" ???
|
||||
|
|
@ -137,44 +140,47 @@ Review
|
|||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
Most languages eventually grow a Boolean type; even C99 (the new
|
||||
and improved C standard, not yet widely adopted) has one.
|
||||
Most languages eventually grow a Boolean type; even C99 (the new
|
||||
and improved C standard, not yet widely adopted) has one.
|
||||
|
||||
Many programmers apparently feel the need for a Boolean type; most
|
||||
Python documentation contains a bit of an apology for the absence
|
||||
of a Boolean type. I've seen lots of modules that defined
|
||||
constants "False=0" and "True=1" (or similar) at the top and used
|
||||
those. The problem with this is that everybody does it
|
||||
differently. For example, should you use "FALSE", "false",
|
||||
"False", "F" or even "f"? And should false be the value zero or
|
||||
None, or perhaps a truth value of a different type that will print
|
||||
as "true" or "false"? Adding a standard bool type to the language
|
||||
resolves those issues.
|
||||
Many programmers apparently feel the need for a Boolean type; most
|
||||
Python documentation contains a bit of an apology for the absence
|
||||
of a Boolean type. I've seen lots of modules that defined
|
||||
constants "False=0" and "True=1" (or similar) at the top and used
|
||||
those. The problem with this is that everybody does it
|
||||
differently. For example, should you use "FALSE", "false",
|
||||
"False", "F" or even "f"? And should false be the value zero or
|
||||
None, or perhaps a truth value of a different type that will print
|
||||
as "true" or "false"? Adding a standard bool type to the language
|
||||
resolves those issues.
|
||||
|
||||
Some external libraries (like databases and RPC packages) need to
|
||||
be able to distinguish between Boolean and integral values, and
|
||||
while it's usually possible to craft a solution, it would be
|
||||
easier if the language offered a standard Boolean type. This also
|
||||
applies to Jython: some Java classes have separately overloaded
|
||||
methods or constructors for int and boolean arguments. The bool
|
||||
type can be used to select the boolean variant. (The same is
|
||||
apparently the case for some COM interfaces.)
|
||||
Some external libraries (like databases and RPC packages) need to
|
||||
be able to distinguish between Boolean and integral values, and
|
||||
while it's usually possible to craft a solution, it would be
|
||||
easier if the language offered a standard Boolean type. This also
|
||||
applies to Jython: some Java classes have separately overloaded
|
||||
methods or constructors for int and boolean arguments. The bool
|
||||
type can be used to select the boolean variant. (The same is
|
||||
apparently the case for some COM interfaces.)
|
||||
|
||||
The standard bool type can also serve as a way to force a value to
|
||||
be interpreted as a Boolean, which can be used to normalize
|
||||
Boolean values. When a Boolean value needs to be normalized to
|
||||
one of two values, bool(x) is much clearer than "not not x" and
|
||||
much more concise than
|
||||
The standard bool type can also serve as a way to force a value to
|
||||
be interpreted as a Boolean, which can be used to normalize
|
||||
Boolean values. When a Boolean value needs to be normalized to
|
||||
one of two values, ``bool(x)`` is much clearer than "not not x" and
|
||||
much more concise than
|
||||
|
||||
::
|
||||
|
||||
if x:
|
||||
return 1
|
||||
else:
|
||||
return 0
|
||||
|
||||
Here are some arguments derived from teaching Python. When
|
||||
showing people comparison operators etc. in the interactive shell,
|
||||
I think this is a bit ugly:
|
||||
Here are some arguments derived from teaching Python. When
|
||||
showing people comparison operators etc. in the interactive shell,
|
||||
I think this is a bit ugly::
|
||||
|
||||
>>> a = 13
|
||||
>>> b = 12
|
||||
|
|
@ -182,18 +188,18 @@ Rationale
|
|||
1
|
||||
>>>
|
||||
|
||||
If this was:
|
||||
If this was::
|
||||
|
||||
>>> a > b
|
||||
True
|
||||
>>>
|
||||
|
||||
it would require a millisecond less thinking each time a 0 or 1
|
||||
was printed.
|
||||
it would require a millisecond less thinking each time a 0 or 1
|
||||
was printed.
|
||||
|
||||
There's also the issue (which I've seen baffling even experienced
|
||||
Pythonistas who had been away from the language for a while) that
|
||||
if you see:
|
||||
There's also the issue (which I've seen baffling even experienced
|
||||
Pythonistas who had been away from the language for a while) that
|
||||
if you see::
|
||||
|
||||
>>> cmp(a, b)
|
||||
1
|
||||
|
|
@ -201,17 +207,18 @@ Rationale
|
|||
0
|
||||
>>>
|
||||
|
||||
you might be tempted to believe that cmp() also returned a truth
|
||||
value, whereas in reality it can return three different values
|
||||
(-1, 0, 1). If ints were not (normally) used to represent
|
||||
Booleans results, this would stand out much more clearly as
|
||||
something completely different.
|
||||
you might be tempted to believe that ``cmp()`` also returned a truth
|
||||
value, whereas in reality it can return three different values
|
||||
``(-1, 0, 1)``. If ints were not (normally) used to represent
|
||||
Booleans results, this would stand out much more clearly as
|
||||
something completely different.
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
The following Python code specifies most of the properties of the
|
||||
new type:
|
||||
The following Python code specifies most of the properties of the
|
||||
new type::
|
||||
|
||||
class bool(int):
|
||||
|
||||
|
|
@ -258,129 +265,135 @@ Specification
|
|||
False = int.__new__(bool, 0)
|
||||
True = int.__new__(bool, 1)
|
||||
|
||||
The values False and True will be singletons, like None. Because
|
||||
the type has two values, perhaps these should be called
|
||||
"doubletons"? The real implementation will not allow other
|
||||
instances of bool to be created.
|
||||
The values ``False`` and ``True`` will be singletons, like None. Because
|
||||
the type has two values, perhaps these should be called
|
||||
"doubletons"? The real implementation will not allow other
|
||||
instances of bool to be created.
|
||||
|
||||
True and False will properly round-trip through pickling and
|
||||
marshalling; for example pickle.loads(pickle.dumps(True)) will
|
||||
return True, and so will marshal.loads(marshal.dumps(True)).
|
||||
``True`` and ``False`` will properly round-trip through pickling and
|
||||
marshalling; for example ``pickle.loads(pickle.dumps(True))`` will
|
||||
return ``True``, and so will ``marshal.loads(marshal.dumps(True))``.
|
||||
|
||||
All built-in operations that are defined to return a Boolean
|
||||
result will be changed to return False or True instead of 0 or 1.
|
||||
In particular, this affects comparisons (<, <=, ==, !=, >, >=, is,
|
||||
is not, in, not in), the unary operator 'not', the built-in
|
||||
functions callable(), hasattr(), isinstance() and issubclass(),
|
||||
the dict method has_key(), the string and unicode methods
|
||||
endswith(), isalnum(), isalpha(), isdigit(), islower(), isspace(),
|
||||
istitle(), isupper(), and startswith(), the unicode methods
|
||||
isdecimal() and isnumeric(), and the 'closed' attribute of file
|
||||
objects. The predicates in the operator module are also changed
|
||||
to return a bool, including operator.truth().
|
||||
All built-in operations that are defined to return a Boolean
|
||||
result will be changed to return ``False`` or ``True`` instead of 0 or 1.
|
||||
In particular, this affects comparisons (``<``, ``<=``, ``==``, ``!=``,
|
||||
``>``, ``>=``, is, is not, in, not in), the unary operator 'not', the built-in
|
||||
functions ``callable()``, ``hasattr()``, ``isinstance()`` and ``issubclass()``,
|
||||
the dict method ``has_key()``, the string and unicode methods
|
||||
``endswith()``, ``isalnum()``, ``isalpha()``, ``isdigit()``, ``islower()``, ``isspace()``,
|
||||
``istitle()``, ``isupper()``, and ``startswith()``, the unicode methods
|
||||
``isdecimal()`` and ``isnumeric()``, and the 'closed' attribute of file
|
||||
objects. The predicates in the operator module are also changed
|
||||
to return a bool, including ``operator.truth()``.
|
||||
|
||||
Because bool inherits from int, True+1 is valid and equals 2, and
|
||||
so on. This is important for backwards compatibility: because
|
||||
comparisons and so on currently return integer values, there's no
|
||||
way of telling what uses existing applications make of these
|
||||
values.
|
||||
Because bool inherits from int, True+1 is valid and equals 2, and
|
||||
so on. This is important for backwards compatibility: because
|
||||
comparisons and so on currently return integer values, there's no
|
||||
way of telling what uses existing applications make of these
|
||||
values.
|
||||
|
||||
It is expected that over time, the standard library will be
|
||||
updated to use False and True when appropriate (but not to require
|
||||
a bool argument type where previous an int was allowed). This
|
||||
change should not pose additional problems and is not specified in
|
||||
detail by this PEP.
|
||||
It is expected that over time, the standard library will be
|
||||
updated to use ``False`` and ``True`` when appropriate (but not to require
|
||||
a bool argument type where previous an int was allowed). This
|
||||
change should not pose additional problems and is not specified in
|
||||
detail by this PEP.
|
||||
|
||||
|
||||
C API
|
||||
=====
|
||||
|
||||
The header file "boolobject.h" defines the C API for the bool
|
||||
type. It is included by "Python.h" so there is no need to include
|
||||
it directly.
|
||||
The header file "boolobject.h" defines the C API for the bool
|
||||
type. It is included by "Python.h" so there is no need to include
|
||||
it directly.
|
||||
|
||||
The existing names Py_False and Py_True reference the unique bool
|
||||
objects False and True (previously these referenced static int
|
||||
objects with values 0 and 1, which were not unique amongst int
|
||||
values).
|
||||
The existing names ``Py_False`` and ``Py_True`` reference the unique bool
|
||||
objects ``False`` and ``True`` (previously these referenced static int
|
||||
objects with values 0 and 1, which were not unique amongst int
|
||||
values).
|
||||
|
||||
A new API, PyObject *PyBool_FromLong(long), takes a C long int
|
||||
argument and returns a new reference to either Py_False (when the
|
||||
argument is zero) or Py_True (when it is nonzero).
|
||||
A new API, ``PyObject *PyBool_FromLong(long)``, takes a C long int
|
||||
argument and returns a new reference to either ``Py_False`` (when the
|
||||
argument is zero) or ``Py_True`` (when it is nonzero).
|
||||
|
||||
To check whether an object is a bool, the macro PyBool_Check() can
|
||||
be used.
|
||||
To check whether an object is a bool, the macro ``PyBool_Check()`` can
|
||||
be used.
|
||||
|
||||
The type of bool instances is PyBoolObject *.
|
||||
The type of bool instances is ``PyBoolObject *``.
|
||||
|
||||
The bool type object is available as PyBool_Type.
|
||||
The bool type object is available as PyBool_Type.
|
||||
|
||||
|
||||
Clarification
|
||||
=============
|
||||
|
||||
This PEP does *not* change the fact that almost all object types
|
||||
can be used as truth values. For example, when used in an if
|
||||
statement, an empty list is false and a non-empty one is true;
|
||||
this does not change and there is no plan to ever change this.
|
||||
This PEP does **not** change the fact that almost all object types
|
||||
can be used as truth values. For example, when used in an if
|
||||
statement, an empty list is false and a non-empty one is true;
|
||||
this does not change and there is no plan to ever change this.
|
||||
|
||||
The only thing that changes is the preferred values to represent
|
||||
truth values when returned or assigned explicitly. Previously,
|
||||
these preferred truth values were 0 and 1; the PEP changes the
|
||||
preferred values to False and True, and changes built-in
|
||||
operations to return these preferred values.
|
||||
The only thing that changes is the preferred values to represent
|
||||
truth values when returned or assigned explicitly. Previously,
|
||||
these preferred truth values were 0 and 1; the PEP changes the
|
||||
preferred values to ``False`` and ``True``, and changes built-in
|
||||
operations to return these preferred values.
|
||||
|
||||
|
||||
Compatibility
|
||||
=============
|
||||
|
||||
Because of backwards compatibility, the bool type lacks many
|
||||
properties that some would like to see. For example, arithmetic
|
||||
operations with one or two bool arguments is allowed, treating
|
||||
False as 0 and True as 1. Also, a bool may be used as a sequence
|
||||
index.
|
||||
Because of backwards compatibility, the bool type lacks many
|
||||
properties that some would like to see. For example, arithmetic
|
||||
operations with one or two bool arguments is allowed, treating
|
||||
``False`` as 0 and ``True`` as 1. Also, a bool may be used as a sequence
|
||||
index.
|
||||
|
||||
I don't see this as a problem, and I don't want evolve the
|
||||
language in this direction either. I don't believe that a
|
||||
stricter interpretation of "Booleanness" makes the language any
|
||||
clearer.
|
||||
I don't see this as a problem, and I don't want evolve the
|
||||
language in this direction either. I don't believe that a
|
||||
stricter interpretation of "Booleanness" makes the language any
|
||||
clearer.
|
||||
|
||||
Another consequence of the compatibility requirement is that the
|
||||
expression "True and 6" has the value 6, and similarly the
|
||||
expression "False or None" has the value None. The "and" and "or"
|
||||
operators are usefully defined to return the first argument that
|
||||
determines the outcome, and this won't change; in particular, they
|
||||
don't force the outcome to be a bool. Of course, if both
|
||||
arguments are bools, the outcome is always a bool. It can also
|
||||
easily be coerced into being a bool by writing for example "bool(x
|
||||
and y)".
|
||||
Another consequence of the compatibility requirement is that the
|
||||
expression "True and 6" has the value 6, and similarly the
|
||||
expression "False or None" has the value None. The "and" and "or"
|
||||
operators are usefully defined to return the first argument that
|
||||
determines the outcome, and this won't change; in particular, they
|
||||
don't force the outcome to be a bool. Of course, if both
|
||||
arguments are bools, the outcome is always a bool. It can also
|
||||
easily be coerced into being a bool by writing for example "bool(x
|
||||
and y)".
|
||||
|
||||
|
||||
Resolved Issues
|
||||
===============
|
||||
|
||||
(See also the Review section above.)
|
||||
(See also the Review section above.)
|
||||
|
||||
- Because the repr() or str() of a bool value is different from an
|
||||
- Because the ``repr()`` or ``str()`` of a bool value is different from an
|
||||
int value, some code (for example doctest-based unit tests, and
|
||||
possibly database code that relies on things like "%s" % truth)
|
||||
may fail. It is easy to work around this (without explicitly
|
||||
referencing the bool type), and it is expected that this only
|
||||
affects a very small amount of code that can easily be fixed.
|
||||
|
||||
- Other languages (C99, C++, Java) name the constants "false" and
|
||||
- Other languages (C99, C++, Java) name the constants "false" and
|
||||
"true", in all lowercase. For Python, I prefer to stick with
|
||||
the example set by the existing built-in constants, which all
|
||||
use CapitalizedWords: None, Ellipsis, NotImplemented (as well as
|
||||
use CapitalizedWords: ``None``, ``Ellipsis``, ``NotImplemented`` (as well as
|
||||
all built-in exceptions). Python's built-in namespace uses all
|
||||
lowercase for functions and types only.
|
||||
|
||||
- It has been suggested that, in order to satisfy user
|
||||
- It has been suggested that, in order to satisfy user
|
||||
expectations, for every x that is considered true in a Boolean
|
||||
context, the expression x == True should be true, and likewise
|
||||
if x is considered false, x == False should be true. In
|
||||
context, the expression ``x == True`` should be true, and likewise
|
||||
if x is considered false, ``x == False`` should be true. In
|
||||
particular newbies who have only just learned about Boolean
|
||||
variables are likely to write
|
||||
::
|
||||
|
||||
if x == True: ...
|
||||
|
||||
instead of the correct form,
|
||||
::
|
||||
|
||||
if x: ...
|
||||
|
||||
|
|
@ -388,29 +401,32 @@ Resolved Issues
|
|||
many people are at first uncomfortable with the latter form, but
|
||||
I believe that the solution should be in education rather than
|
||||
in crippling the language. After all, == is general seen as a
|
||||
transitive operator, meaning that from a==b and b==c we can
|
||||
deduce a==c. But if any comparison to True were to report
|
||||
transitive operator, meaning that from ``a==b`` and ``b==c`` we can
|
||||
deduce ``a==c``. But if any comparison to ``True`` were to report
|
||||
equality when the other operand was a true value of any type,
|
||||
atrocities like 6==True==7 would hold true, from which one could
|
||||
infer the falsehood 6==7. That's unacceptable. (In addition,
|
||||
atrocities like ``6==True==7`` would hold true, from which one could
|
||||
infer the falsehood ``6==7``. That's unacceptable. (In addition,
|
||||
it would break backwards compatibility. But even if it didn't,
|
||||
I'd still be against this, for the stated reasons.)
|
||||
|
||||
Newbies should also be reminded that there's never a reason to
|
||||
write
|
||||
::
|
||||
|
||||
if bool(x): ...
|
||||
|
||||
since the bool is implicit in the "if". Explicit is *not*
|
||||
since the bool is implicit in the "if". Explicit is **not**
|
||||
better than implicit here, since the added verbiage impairs
|
||||
redability and there's no other interpretation possible. There
|
||||
is, however, sometimes a reason to write
|
||||
::
|
||||
|
||||
b = bool(x)
|
||||
|
||||
This is useful when it is unattractive to keep a reference to an
|
||||
arbitrary object x, or when normalization is required for some
|
||||
other reason. It is also sometimes appropriate to write
|
||||
::
|
||||
|
||||
i = int(bool(x))
|
||||
|
||||
|
|
@ -419,23 +435,23 @@ Resolved Issues
|
|||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
A complete implementation in C has been uploaded to the
|
||||
SourceForge patch manager:
|
||||
A complete implementation in C has been uploaded to the
|
||||
SourceForge patch manager: http://python.org/sf/528022
|
||||
|
||||
http://python.org/sf/528022
|
||||
|
||||
This will soon be checked into CVS for python 2.3a0.
|
||||
This will soon be checked into CVS for python 2.3a0.
|
||||
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
||||
This document has been placed in the public domain.
|
||||
This document has been placed in the public domain.
|
||||
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
fill-column: 70
|
||||
End:
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
fill-column: 70
|
||||
End:
|
||||
|
|
|
|||
Loading…
Reference in New Issue