Mariatta
Brett Cannon
parent
e788aa9084
commit
927e704d7e
82
pep-0160.txt
82
pep-0160.txt
|
|
@ -5,73 +5,79 @@ Last-Modified: $Date$
|
|||
Author: Fred L. Drake, Jr. <fdrake@acm.org>
|
||||
Status: Final
|
||||
Type: Informational
|
||||
Content-Type: text/x-rst
|
||||
Created: 25-Jul-2000
|
||||
Python-Version: 1.6
|
||||
Post-History:
|
||||
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
This PEP describes the Python 1.6 release schedule. The CVS
|
||||
revision history of this file contains the definitive historical
|
||||
record.
|
||||
This PEP describes the Python 1.6 release schedule. The CVS
|
||||
revision history of this file contains the definitive historical
|
||||
record.
|
||||
|
||||
This release will be produced by BeOpen PythonLabs staff for the
|
||||
Corporation for National Research Initiatives (CNRI).
|
||||
This release will be produced by BeOpen PythonLabs staff for the
|
||||
Corporation for National Research Initiatives (CNRI).
|
||||
|
||||
|
||||
Schedule
|
||||
========
|
||||
|
||||
August 1 1.6 beta 1 release (planned).
|
||||
August 3 1.6 beta 1 release (actual).
|
||||
August 15 1.6 final release (planned).
|
||||
September 5 1.6 final release (actual).
|
||||
* August 1: 1.6 beta 1 release (planned).
|
||||
* August 3: 1.6 beta 1 release (actual).
|
||||
* August 15: 1.6 final release (planned).
|
||||
* September 5: 1.6 final release (actual).
|
||||
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
A number of features are required for Python 1.6 in order to
|
||||
fulfill the various promises that have been made. The following
|
||||
are required to be fully operational, documented, and forward
|
||||
compatible with the plans for Python 2.0:
|
||||
A number of features are required for Python 1.6 in order to
|
||||
fulfill the various promises that have been made. The following
|
||||
are required to be fully operational, documented, and forward
|
||||
compatible with the plans for Python 2.0:
|
||||
|
||||
* Unicode support: The Unicode object defined for Python 2.0 must
|
||||
be provided, including all methods and codec support.
|
||||
* Unicode support: The Unicode object defined for Python 2.0 must be provided,
|
||||
including all methods and codec support.
|
||||
|
||||
* SRE: Fredrik Lundh's new regular expression engine will be used
|
||||
to provide support for both 8-bit strings and Unicode strings.
|
||||
It must pass the regression test used for the pcre-based version
|
||||
of the re module.
|
||||
* SRE: Fredrik Lundh's new regular expression engine will be used
|
||||
to provide support for both 8-bit strings and Unicode strings. It must pass
|
||||
the regression test used for the pcre-based version of the re module.
|
||||
|
||||
* The curses module was in the middle of a transformation to a
|
||||
package, so the final form was adopted.
|
||||
* The curses module was in the middle of a transformation to a package, so the
|
||||
final form was adopted.
|
||||
|
||||
|
||||
Mechanism
|
||||
=========
|
||||
|
||||
The release will be created as a branch from the development tree
|
||||
rooted at CNRI's close of business on 16 May 2000. Patches
|
||||
required from more recent checkins will be merged in by moving the
|
||||
branch tag on individual files whenever possible in order to
|
||||
reduce mailing list clutter and avoid divergent and incompatible
|
||||
implementations.
|
||||
The release will be created as a branch from the development tree
|
||||
rooted at CNRI's close of business on 16 May 2000. Patches
|
||||
required from more recent checkins will be merged in by moving the
|
||||
branch tag on individual files whenever possible in order to
|
||||
reduce mailing list clutter and avoid divergent and incompatible
|
||||
implementations.
|
||||
|
||||
The branch tag is "cnri-16-start".
|
||||
The branch tag is "cnri-16-start".
|
||||
|
||||
Patches and features will be merged to the extent required to pass
|
||||
regression tests in effect on 16 May 2000.
|
||||
Patches and features will be merged to the extent required to pass
|
||||
regression tests in effect on 16 May 2000.
|
||||
|
||||
The beta release is tagged "r16b1" in the CVS repository, and the
|
||||
final Python 1.6 release is tagged "release16" in the repository.
|
||||
The beta release is tagged "r16b1" in the CVS repository, and the
|
||||
final Python 1.6 release is tagged "release16" in the repository.
|
||||
|
||||
|
||||
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
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
12
pep-0210.txt
12
pep-0210.txt
|
|
@ -5,13 +5,15 @@ Last-Modified: $Date$
|
|||
Author: davida@activestate.com (David Ascher)
|
||||
Status: Rejected
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 15-Jul-2000
|
||||
Python-Version: 2.1
|
||||
Post-History:
|
||||
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
63
pep-0217.txt
63
pep-0217.txt
|
|
@ -5,38 +5,44 @@ Last-Modified: $Date$
|
|||
Author: moshez@zadka.site.co.il (Moshe Zadka)
|
||||
Status: Final
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 31-Jul-2000
|
||||
Python-Version: 2.1
|
||||
Post-History:
|
||||
Post-History:
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
Python's interactive mode is one of the implementation's great
|
||||
strengths -- being able to write expressions on the command line
|
||||
and get back a meaningful output. However, the output function
|
||||
cannot be all things to all people, and the current output
|
||||
function too often falls short of this goal. This PEP describes a
|
||||
way to provides alternatives to the built-in display function in
|
||||
Python, so users will have control over the output from the
|
||||
interactive interpreter.
|
||||
|
||||
Python's interactive mode is one of the implementation's great
|
||||
strengths -- being able to write expressions on the command line
|
||||
and get back a meaningful output. However, the output function
|
||||
cannot be all things to all people, and the current output
|
||||
function too often falls short of this goal. This PEP describes a
|
||||
way to provides alternatives to the built-in display function in
|
||||
Python, so users will have control over the output from the
|
||||
interactive interpreter.
|
||||
|
||||
Interface
|
||||
=========
|
||||
|
||||
The current Python solution has worked for many users, and this
|
||||
should not break it. Therefore, in the default configuration,
|
||||
nothing will change in the REPL loop. To change the way the
|
||||
interpreter prints interactively entered expressions, users
|
||||
will have to rebind ``sys.displayhook`` to a callable object.
|
||||
The result of calling this object with the result of the
|
||||
interactively entered expression should be print-able,
|
||||
and this is what will be printed on ``sys.stdout``.
|
||||
|
||||
The current Python solution has worked for many users, and this
|
||||
should not break it. Therefore, in the default configuration,
|
||||
nothing will change in the REPL loop. To change the way the
|
||||
interpreter prints interactively entered expressions, users
|
||||
will have to rebind sys.displayhook to a callable object.
|
||||
The result of calling this object with the result of the
|
||||
interactively entered expression should be print-able,
|
||||
and this is what will be printed on sys.stdout.
|
||||
|
||||
Solution
|
||||
========
|
||||
|
||||
The bytecode PRINT_EXPR will call sys.displayhook(POP())
|
||||
A displayhook() will be added to the sys builtin module, which is
|
||||
equivalent to
|
||||
The bytecode ``PRINT_EXPR`` will call ``sys.displayhook(POP())``.
|
||||
A ``displayhook()`` will be added to the sys builtin module, which is
|
||||
equivalent to::
|
||||
|
||||
import __builtin__
|
||||
def displayhook(o):
|
||||
|
|
@ -45,13 +51,16 @@ Solution
|
|||
__builtin__._ = None
|
||||
print `o`
|
||||
__builtin__._ = o
|
||||
|
||||
|
||||
|
||||
Jython Issues
|
||||
=============
|
||||
|
||||
The method Py.printResult will be similarly changed.
|
||||
The method ``Py.printResult`` will be similarly changed.
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
27
pep-0220.txt
27
pep-0220.txt
|
|
@ -5,23 +5,26 @@ Last-Modified: $Date$
|
|||
Author: gmcm@hypernet.com (Gordon McMillan)
|
||||
Status: Rejected
|
||||
Type: Informational
|
||||
Content-Type: text/x-rst
|
||||
Created: 14-Aug-2000
|
||||
Post-History:
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
Demonstrates why the changes described in the stackless PEP are
|
||||
desirable. A low-level continuations module exists. With it,
|
||||
coroutines and generators and "green" threads can be written. A
|
||||
higher level module that makes coroutines and generators easy to
|
||||
create is desirable (and being worked on). The focus of this PEP
|
||||
is on showing how coroutines, generators, and green threads can
|
||||
simplify common programming problems.
|
||||
Demonstrates why the changes described in the stackless PEP are
|
||||
desirable. A low-level continuations module exists. With it,
|
||||
coroutines and generators and "green" threads can be written. A
|
||||
higher level module that makes coroutines and generators easy to
|
||||
create is desirable (and being worked on). The focus of this PEP
|
||||
is on showing how coroutines, generators, and green threads can
|
||||
simplify common programming problems.
|
||||
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
127
pep-0233.txt
127
pep-0233.txt
|
|
@ -5,95 +5,114 @@ Last-Modified: $Date$
|
|||
Author: paul@prescod.net (Paul Prescod)
|
||||
Status: Deferred
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 11-Dec-2000
|
||||
Python-Version: 2.1
|
||||
Post-History:
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This PEP describes a command-line driven online help facility for
|
||||
Python. The facility should be able to build on existing
|
||||
documentation facilities such as the Python documentation and
|
||||
docstrings. It should also be extensible for new types and
|
||||
modules.
|
||||
This PEP describes a command-line driven online help facility for
|
||||
Python. The facility should be able to build on existing
|
||||
documentation facilities such as the Python documentation and
|
||||
docstrings. It should also be extensible for new types and
|
||||
modules.
|
||||
|
||||
|
||||
Interactive use:
|
||||
Interactive use
|
||||
===============
|
||||
|
||||
Simply typing "help" describes the help function (through repr()
|
||||
overloading).
|
||||
Simply typing "help" describes the help function (through ``repr()``
|
||||
overloading).
|
||||
|
||||
"help" can also be used as a function:
|
||||
"help" can also be used as a function.
|
||||
|
||||
The function takes the following forms of input:
|
||||
The function takes the following forms of input::
|
||||
|
||||
help( "string" ) -- built-in topic or global
|
||||
help( <ob> ) -- docstring from object or type
|
||||
help( "doc:filename" ) -- filename from Python documentation
|
||||
help( "string" ) -- built-in topic or global
|
||||
help( <ob> ) -- docstring from object or type
|
||||
help( "doc:filename" ) -- filename from Python documentation
|
||||
|
||||
If you ask for a global, it can be a fully-qualified name such as
|
||||
help("xml.dom").
|
||||
If you ask for a global, it can be a fully-qualified name, such as::
|
||||
|
||||
You can also use the facility from a command-line
|
||||
help("xml.dom")
|
||||
|
||||
You can also use the facility from a command-line::
|
||||
|
||||
python --help if
|
||||
|
||||
In either situation, the output does paging similar to the "more"
|
||||
command.
|
||||
In either situation, the output does paging similar to the "more"
|
||||
command.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
The help function is implemented in an onlinehelp module which is
|
||||
demand-loaded.
|
||||
The help function is implemented in an ``onlinehelp`` module which is
|
||||
demand-loaded.
|
||||
|
||||
There should be options for fetching help information from
|
||||
environments other than the command line through the onlinehelp
|
||||
module:
|
||||
There should be options for fetching help information from
|
||||
environments other than the command line through the ``onlinehelp``
|
||||
module::
|
||||
|
||||
onlinehelp.gethelp(object_or_string) -> string
|
||||
onlinehelp.gethelp(object_or_string) -> string
|
||||
|
||||
It should also be possible to override the help display function
|
||||
by assigning to onlinehelp.displayhelp(object_or_string).
|
||||
It should also be possible to override the help display function
|
||||
by assigning to ``onlinehelp``.displayhelp(object_or_string).
|
||||
|
||||
The module should be able to extract module information from
|
||||
either the HTML or LaTeX versions of the Python documentation.
|
||||
Links should be accommodated in a "lynx-like" manner.
|
||||
The module should be able to extract module information from
|
||||
either the HTML or LaTeX versions of the Python documentation.
|
||||
Links should be accommodated in a "lynx-like" manner.
|
||||
|
||||
Over time, it should also be able to recognize when docstrings are
|
||||
in "special" syntaxes like structured text, HTML and LaTeX and
|
||||
decode them appropriately.
|
||||
Over time, it should also be able to recognize when docstrings are
|
||||
in "special" syntaxes like structured text, HTML and LaTeX and
|
||||
decode them appropriately.
|
||||
|
||||
A prototype implementation is available with the Python source
|
||||
distribution as nondist/sandbox/doctools/onlinehelp.py.
|
||||
A prototype implementation is available with the Python source
|
||||
distribution as nondist/sandbox/doctools/``onlinehelp``.py.
|
||||
|
||||
|
||||
Built-in Topics
|
||||
===============
|
||||
|
||||
help( "intro" ) - What is Python? Read this first!
|
||||
help( "keywords" ) - What are the keywords?
|
||||
help( "syntax" ) - What is the overall syntax?
|
||||
help( "operators" ) - What operators are available?
|
||||
help( "builtins" ) - What functions, types, etc. are built-in?
|
||||
help( "modules" ) - What modules are in the standard library?
|
||||
help( "copyright" ) - Who owns Python?
|
||||
help( "moreinfo" ) - Where is there more information?
|
||||
help( "changes" ) - What changed in Python 2.0?
|
||||
help( "extensions" ) - What extensions are installed?
|
||||
help( "faq" ) - What questions are frequently asked?
|
||||
help( "ack" ) - Who has done work on Python lately?
|
||||
help( "intro" ) - What is Python? Read this first!
|
||||
|
||||
help( "keywords" ) - What are the keywords?
|
||||
|
||||
help( "syntax" ) - What is the overall syntax?
|
||||
|
||||
help( "operators" ) - What operators are available?
|
||||
|
||||
help( "builtins" ) - What functions, types, etc. are built-in?
|
||||
|
||||
help( "modules" ) - What modules are in the standard library?
|
||||
|
||||
help( "copyright" ) - Who owns Python?
|
||||
|
||||
help( "moreinfo" ) - Where is there more information?
|
||||
|
||||
help( "changes" ) - What changed in Python 2.0?
|
||||
|
||||
help( "extensions" ) - What extensions are installed?
|
||||
|
||||
help( "faq" ) - What questions are frequently asked?
|
||||
|
||||
help( "ack" ) - Who has done work on Python lately?
|
||||
|
||||
|
||||
Security Issues
|
||||
===============
|
||||
|
||||
This module will attempt to import modules with the same names as
|
||||
requested topics. Don't use the modules if you are not confident
|
||||
that everything in your PYTHONPATH is from a trusted source.
|
||||
This module will attempt to import modules with the same names as
|
||||
requested topics. Don't use the modules if you are not confident
|
||||
that everything in your ``PYTHONPATH`` is from a trusted source.
|
||||
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
100
pep-0251.txt
100
pep-0251.txt
|
|
@ -5,85 +5,95 @@ Last-Modified: $Date$
|
|||
Author: barry@python.org (Barry Warsaw), guido@python.org (Guido van Rossum)
|
||||
Status: Final
|
||||
Type: Informational
|
||||
Content-Type: text/x-rst
|
||||
Created: 17-Apr-2001
|
||||
Python-Version: 2.2
|
||||
Post-History: 14-Aug-2001
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This document describes the Python 2.2 development and release
|
||||
schedule. The schedule primarily concerns itself with PEP-sized
|
||||
items. Small bug fixes and changes will occur up until the first
|
||||
beta release.
|
||||
This document describes the Python 2.2 development and release
|
||||
schedule. The schedule primarily concerns itself with PEP-sized
|
||||
items. Small bug fixes and changes will occur up until the first
|
||||
beta release.
|
||||
|
||||
The schedule below represents the actual release dates of Python
|
||||
2.2. Note that any subsequent maintenance releases of Python 2.2
|
||||
should be covered by separate PEPs.
|
||||
The schedule below represents the actual release dates of Python
|
||||
2.2. Note that any subsequent maintenance releases of Python 2.2
|
||||
should be covered by separate PEPs.
|
||||
|
||||
|
||||
Release Schedule
|
||||
================
|
||||
|
||||
Tentative future release dates. Note that we've slipped this
|
||||
compared to the schedule posted around the release of 2.2a1.
|
||||
Tentative future release dates. Note that we've slipped this
|
||||
compared to the schedule posted around the release of 2.2a1.
|
||||
|
||||
21-Dec-2001: 2.2 [Released] (final release)
|
||||
14-Dec-2001: 2.2c1 [Released]
|
||||
14-Nov-2001: 2.2b2 [Released]
|
||||
19-Oct-2001: 2.2b1 [Released]
|
||||
28-Sep-2001: 2.2a4 [Released]
|
||||
7-Sep-2001: 2.2a3 [Released]
|
||||
22-Aug-2001: 2.2a2 [Released]
|
||||
18-Jul-2001: 2.2a1 [Released]
|
||||
* 21-Dec-2001: 2.2 [Released] (final release)
|
||||
* 14-Dec-2001: 2.2c1 [Released]
|
||||
* 14-Nov-2001: 2.2b2 [Released]
|
||||
* 19-Oct-2001: 2.2b1 [Released]
|
||||
* 28-Sep-2001: 2.2a4 [Released]
|
||||
* 7-Sep-2001: 2.2a3 [Released]
|
||||
* 22-Aug-2001: 2.2a2 [Released]
|
||||
* 18-Jul-2001: 2.2a1 [Released]
|
||||
|
||||
|
||||
Release Manager
|
||||
===============
|
||||
|
||||
Barry Warsaw was the Python 2.2 release manager.
|
||||
Barry Warsaw was the Python 2.2 release manager.
|
||||
|
||||
|
||||
Release Mechanics
|
||||
=================
|
||||
|
||||
We experimented with a new mechanism for releases: a week before
|
||||
every alpha, beta or other release, we forked off a branch which
|
||||
became the release. Changes to the branch are limited to the
|
||||
release manager and his designated 'bots. This experiment was
|
||||
deemed a success and should be observed for future releases. See
|
||||
PEP 101 for the actual release mechanics[1].
|
||||
We experimented with a new mechanism for releases: a week before
|
||||
every alpha, beta or other release, we forked off a branch which
|
||||
became the release. Changes to the branch are limited to the
|
||||
release manager and his designated 'bots. This experiment was
|
||||
deemed a success and should be observed for future releases. See
|
||||
PEP 101 for the actual release mechanics [1]_.
|
||||
|
||||
|
||||
New features for Python 2.2
|
||||
===========================
|
||||
|
||||
The following new features are introduced in Python 2.2. For a
|
||||
more detailed account, see Misc/NEWS[2] in the Python
|
||||
distribution, or Andrew Kuchling's "What's New in Python 2.2"
|
||||
document[3].
|
||||
The following new features are introduced in Python 2.2. For a
|
||||
more detailed account, see Misc/NEWS [2]_ in the Python
|
||||
distribution, or Andrew Kuchling's "What's New in Python 2.2"
|
||||
document [3]_.
|
||||
|
||||
- iterators (PEP 234)
|
||||
- generators (PEP 255)
|
||||
- unifying long ints and plain ints (PEP 237)
|
||||
- division (PEP 238)
|
||||
- unification of types and classes (PEP 252, PEP 253)
|
||||
- iterators (PEP 234)
|
||||
- generators (PEP 255)
|
||||
- unifying long ints and plain ints (PEP 237)
|
||||
- division (PEP 238)
|
||||
- unification of types and classes (PEP 252, PEP 253)
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] PEP 101, Doing Python Releases 101
|
||||
http://www.python.org/dev/peps/pep-0101/
|
||||
.. [1] PEP 101, Doing Python Releases 101
|
||||
http://www.python.org/dev/peps/pep-0101/
|
||||
|
||||
[2] Misc/NEWS file from CVS
|
||||
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/NEWS?rev=1.337.2.4&content-type=text/vnd.viewcvs-markup
|
||||
.. [2] Misc/NEWS file from CVS
|
||||
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/NEWS?rev=1.337.2.4&content-type=text/vnd.viewcvs-markup
|
||||
|
||||
[3] Andrew Kuchling, What's New in Python 2.2
|
||||
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html
|
||||
.. [3] Andrew Kuchling, What's New in Python 2.2
|
||||
http://www.python.org/doc/2.2.1/whatsnew/whatsnew22.html
|
||||
|
||||
|
||||
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
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
29
pep-0254.txt
29
pep-0254.txt
|
|
@ -5,27 +5,34 @@ Last-Modified: $Date$
|
|||
Author: guido@python.org (Guido van Rossum)
|
||||
Status: Rejected
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 18-June-2001
|
||||
Python-Version: 2.2
|
||||
Post-History:
|
||||
|
||||
Abstract
|
||||
|
||||
This PEP has not been written yet. Watch this space!
|
||||
Abstract
|
||||
========
|
||||
|
||||
This PEP has not been written yet. Watch this space!
|
||||
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
This PEP was a stub entry and eventually abandoned without having
|
||||
been filled-out. Substantially most of the intended functionality
|
||||
was implemented in Py2.2 with new-style types and classes.
|
||||
This PEP was a stub entry and eventually abandoned without having
|
||||
been filled-out. Substantially most of the intended functionality
|
||||
was implemented in Py2.2 with new-style types and classes.
|
||||
|
||||
|
||||
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
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
94
pep-0260.txt
94
pep-0260.txt
|
|
@ -5,81 +5,91 @@ Last-Modified: $Date$
|
|||
Author: guido@python.org (Guido van Rossum)
|
||||
Status: Final
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 26-Jun-2001
|
||||
Python-Version: 2.2
|
||||
Post-History: 26-Jun-2001
|
||||
|
||||
Abstract
|
||||
|
||||
This PEP proposes to strip the xrange() object from some rarely
|
||||
used behavior like x[i:j] and x*n.
|
||||
Abstract
|
||||
========
|
||||
|
||||
This PEP proposes to strip the ``xrange()`` object from some rarely
|
||||
used behavior like ``x[i:j]`` and ``x*n``.
|
||||
|
||||
|
||||
Problem
|
||||
=======
|
||||
|
||||
The xrange() function has one idiomatic use:
|
||||
The ``xrange()`` function has one idiomatic use::
|
||||
|
||||
for i in xrange(...): ...
|
||||
for i in xrange(...): ...
|
||||
|
||||
However, the xrange() object has a bunch of rarely used behaviors
|
||||
that attempt to make it more sequence-like. These are so rarely
|
||||
used that historically they have has serious bugs (e.g. off-by-one
|
||||
errors) that went undetected for several releases.
|
||||
However, the xrange() object has a bunch of rarely used behaviors
|
||||
that attempt to make it more sequence-like. These are so rarely
|
||||
used that historically they have has serious bugs (e.g. off-by-one
|
||||
errors) that went undetected for several releases.
|
||||
|
||||
I claim that it's better to drop these unused features. This will
|
||||
simplify the implementation, testing, and documentation, and
|
||||
reduce maintenance and code size.
|
||||
I claim that it's better to drop these unused features. This will
|
||||
simplify the implementation, testing, and documentation, and
|
||||
reduce maintenance and code size.
|
||||
|
||||
|
||||
Proposed Solution
|
||||
=================
|
||||
|
||||
I propose to strip the xrange() object to the bare minimum. The
|
||||
only retained sequence behaviors are x[i], len(x), and repr(x).
|
||||
In particular, these behaviors will be dropped:
|
||||
I propose to strip the `xrange()` object to the bare minimum. The
|
||||
only retained sequence behaviors are x[i], len(x), and repr(x).
|
||||
In particular, these behaviors will be dropped::
|
||||
|
||||
x[i:j] (slicing)
|
||||
x*n, n*x (sequence-repeat)
|
||||
cmp(x1, x2) (comparisons)
|
||||
i in x (containment test)
|
||||
x.tolist() method
|
||||
x.start, x.stop, x.step attributes
|
||||
x[i:j] (slicing)
|
||||
x*n, n*x (sequence-repeat)
|
||||
cmp(x1, x2) (comparisons)
|
||||
i in x (containment test)
|
||||
x.tolist() method
|
||||
x.start, x.stop, x.step attributes
|
||||
|
||||
I also propose to change the signature of the PyRange_New() C API
|
||||
to remove the 4th argument (the repetition count).
|
||||
I also propose to change the signature of the `PyRange_New()` C API
|
||||
to remove the 4th argument (the repetition count).
|
||||
|
||||
By implementing a custom iterator type, we could speed up the
|
||||
common use, but this is optional (the default sequence iterator
|
||||
does just fine).
|
||||
By implementing a custom iterator type, we could speed up the
|
||||
common use, but this is optional (the default sequence iterator
|
||||
does just fine).
|
||||
|
||||
|
||||
Scope
|
||||
=====
|
||||
|
||||
This PEP affects the xrange() built-in function and the
|
||||
PyRange_New() C API.
|
||||
This PEP affects the `xrange()` built-in function and the
|
||||
`PyRange_New()` C API.
|
||||
|
||||
|
||||
Risks
|
||||
=====
|
||||
|
||||
Somebody's code could be relying on the extended code, and this
|
||||
code would break. However, given that historically bugs in the
|
||||
extended code have gone undetected for so long, it's unlikely that
|
||||
much code is affected.
|
||||
Somebody's code could be relying on the extended code, and this
|
||||
code would break. However, given that historically bugs in the
|
||||
extended code have gone undetected for so long, it's unlikely that
|
||||
much code is affected.
|
||||
|
||||
|
||||
Transition
|
||||
==========
|
||||
|
||||
For backwards compatibility, the existing functionality will still
|
||||
be present in Python 2.2, but will trigger a warning. A year
|
||||
after Python 2.2 final is released (probably in 2.4) the
|
||||
functionality will be ripped out.
|
||||
For backwards compatibility, the existing functionality will still
|
||||
be present in Python 2.2, but will trigger a warning. A year
|
||||
after Python 2.2 final is released (probably in 2.4) the
|
||||
functionality will be ripped out.
|
||||
|
||||
|
||||
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
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
|
|
|
|||
85
pep-0270.txt
85
pep-0270.txt
|
|
@ -5,79 +5,88 @@ Last-Modified: $Date$
|
|||
Author: jp@demonseed.net (Jason Petrone)
|
||||
Status: Rejected
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 21-Aug-2001
|
||||
Python-Version: 2.2
|
||||
Post-History:
|
||||
|
||||
|
||||
Notice
|
||||
======
|
||||
|
||||
This PEP is withdrawn by the author. He writes:
|
||||
This PEP is withdrawn by the author. He writes::
|
||||
|
||||
Removing duplicate elements from a list is a common task, but
|
||||
there are only two reasons I can see for making it a built-in.
|
||||
The first is if it could be done much faster, which isn't the
|
||||
case. The second is if it makes it significantly easier to
|
||||
write code. The introduction of sets.py eliminates this
|
||||
situation since creating a sequence without duplicates is just
|
||||
a matter of choosing a different data structure: a set instead
|
||||
of a list.
|
||||
Removing duplicate elements from a list is a common task, but
|
||||
there are only two reasons I can see for making it a built-in.
|
||||
The first is if it could be done much faster, which isn't the
|
||||
case. The second is if it makes it significantly easier to
|
||||
write code. The introduction of sets.py eliminates this
|
||||
situation since creating a sequence without duplicates is just
|
||||
a matter of choosing a different data structure: a set instead
|
||||
of a list.
|
||||
|
||||
As described in PEP 218, sets are being added to the standard
|
||||
library for Python 2.3.
|
||||
As described in PEP 218, sets are being added to the standard
|
||||
library for Python 2.3.
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
This PEP proposes adding a method for removing duplicate elements to
|
||||
the list object.
|
||||
This PEP proposes adding a method for removing duplicate elements to
|
||||
the list object.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
Removing duplicates from a list is a common task. I think it is
|
||||
useful and general enough to belong as a method in list objects.
|
||||
It also has potential for faster execution when implemented in C,
|
||||
especially if optimization using hashing or sorted cannot be used.
|
||||
Removing duplicates from a list is a common task. I think it is
|
||||
useful and general enough to belong as a method in list objects.
|
||||
It also has potential for faster execution when implemented in C,
|
||||
especially if optimization using hashing or sorted cannot be used.
|
||||
|
||||
On comp.lang.python there are many, many, posts[1] asking about
|
||||
the best way to do this task. Its a little tricky to implement
|
||||
optimally and it would be nice to save people the trouble of
|
||||
figuring it out themselves.
|
||||
On comp.lang.python there are many, many, posts [1]_ asking about
|
||||
the best way to do this task. It's a little tricky to implement
|
||||
optimally and it would be nice to save people the trouble of
|
||||
figuring it out themselves.
|
||||
|
||||
|
||||
Considerations
|
||||
==============
|
||||
|
||||
Tim Peters suggests trying to use a hash table, then trying to
|
||||
sort, and finally falling back on brute force[2]. Should uniq
|
||||
maintain list order at the expense of speed?
|
||||
Tim Peters suggests trying to use a hash table, then trying to
|
||||
sort, and finally falling back on brute force [2]_. Should uniq
|
||||
maintain list order at the expense of speed?
|
||||
|
||||
Is it spelled 'uniq' or 'unique'?
|
||||
Is it spelled 'uniq' or 'unique'?
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
I've written the brute force version. Its about 20 lines of code
|
||||
in listobject.c. Adding support for hash table and sorted
|
||||
duplicate removal would only take another hour or so.
|
||||
I've written the brute force version. It's about 20 lines of code
|
||||
in listobject.c. Adding support for hash table and sorted
|
||||
duplicate removal would only take another hour or so.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] http://groups.google.com/groups?as_q=duplicates&as_ugroup=comp.lang.python
|
||||
.. [1] http://groups.google.com/groups?as_q=duplicates&as_ugroup=comp.lang.python
|
||||
|
||||
[2] Tim Peters unique() entry in the Python cookbook:
|
||||
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52560/index_txt
|
||||
.. [2] Tim Peters unique() entry in the Python cookbook::
|
||||
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52560/index_txt
|
||||
|
||||
|
||||
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:
|
||||
|
|
|
|||
70
pep-0271.txt
70
pep-0271.txt
|
|
@ -2,76 +2,84 @@ PEP: 271
|
|||
Title: Prefixing sys.path by command line option
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: fred@arakne.com (Frédéric B. Giacometti)
|
||||
Author: fred@arakne.com (Frédéric B. Giacometti)
|
||||
Status: Rejected
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
Created: 15-Aug-2001
|
||||
Python-Version: 2.2
|
||||
Post-History:
|
||||
|
||||
|
||||
Abstract
|
||||
========
|
||||
|
||||
At present, setting the PYTHONPATH environment variable is the
|
||||
only method for defining additional Python module search
|
||||
directories.
|
||||
At present, setting the ``PYTHONPATH`` environment variable is the
|
||||
only method for defining additional Python module search
|
||||
directories.
|
||||
|
||||
This PEP introduces the '-P' valued option to the python command
|
||||
as an alternative to PYTHONPATH.
|
||||
This PEP introduces the '-P' valued option to the python command
|
||||
as an alternative to ``PYTHONPATH``.
|
||||
|
||||
|
||||
Rationale
|
||||
=========
|
||||
|
||||
On Unix:
|
||||
On Unix::
|
||||
|
||||
python -P $SOMEVALUE
|
||||
python -P $SOMEVALUE
|
||||
|
||||
will be equivalent to
|
||||
will be equivalent to::
|
||||
|
||||
env PYTHONPATH=$SOMEVALUE python
|
||||
env PYTHONPATH=$SOMEVALUE python
|
||||
|
||||
On Windows 2K:
|
||||
On Windows 2K::
|
||||
|
||||
python -P %SOMEVALUE%
|
||||
python -P %SOMEVALUE%
|
||||
|
||||
will (almost) be equivalent to
|
||||
will (almost) be equivalent to::
|
||||
|
||||
set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE%\
|
||||
&& python && set PYTHONPATH=%__PYTHONPATH%
|
||||
|
||||
set __PYTHONPATH=%PYTHONPATH% && set PYTHONPATH=%SOMEVALUE%\
|
||||
&& python && set PYTHONPATH=%__PYTHONPATH%
|
||||
|
||||
|
||||
Other Information
|
||||
=================
|
||||
|
||||
This option is equivalent to the 'java -classpath' option.
|
||||
This option is equivalent to the 'java -classpath' option.
|
||||
|
||||
|
||||
When to use this option
|
||||
=======================
|
||||
|
||||
This option is intended to ease and make more robust the use of
|
||||
Python in test or build scripts, for instance.
|
||||
This option is intended to ease and make more robust the use of
|
||||
Python in test or build scripts, for instance.
|
||||
|
||||
|
||||
Reference Implementation
|
||||
========================
|
||||
|
||||
A patch implementing this is available from SourceForge:
|
||||
A patch implementing this is available from SourceForge::
|
||||
|
||||
http://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=6916&aid=429614
|
||||
|
||||
with the patch discussion at:
|
||||
|
||||
with the patch discussion at::
|
||||
|
||||
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=429614&group_id=5470
|
||||
|
||||
|
||||
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
|
||||
sentence-end-double-space: t
|
||||
fill-column: 70
|
||||
coding: utf-8
|
||||
End:
|
||||
|
||||
..
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
sentence-end-double-space: t
|
||||
fill-column: 70
|
||||
coding: utf-8
|
||||
End:
|
||||
|
|
|
|||
Loading…
Reference in New Issue