iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Another batch of 10 PEPs converted (#177)

This commit is contained in:
Mariatta 2017-01-10 11:30:39 -08:00 committed by Brett Cannon
parent b54f01e13f
commit 08282fe6a5
10 changed files with 883 additions and 777 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

141
pep-0215.txt
View File

@ -5,65 +5,71 @@ Last-Modified: $Date$
Author: ping@zesty.ca (Ka-Ping Yee)
Status: Superseded
Type: Standards Track
Content-Type: text/x-rst
Created: 24-Jul-2000
Python-Version: 2.1
Post-History:
Superseded-By: 292
Abstract
This document proposes a string interpolation feature for Python
to allow easier string formatting. The suggested syntax change
is the introduction of a '$' prefix that triggers the special
interpretation of the '$' character within a string, in a manner
reminiscent to the variable interpolation found in Unix shells,
awk, Perl, or Tcl.
Abstract
========
This document proposes a string interpolation feature for Python
to allow easier string formatting. The suggested syntax change
is the introduction of a '$' prefix that triggers the special
interpretation of the '$' character within a string, in a manner
reminiscent to the variable interpolation found in Unix shells,
awk, Perl, or Tcl.
Copyright
=========
This document is in the public domain.
This document is in the public domain.
Specification
=============
Strings may be preceded with a '$' prefix that comes before the
leading single or double quotation mark (or triplet) and before
any of the other string prefixes ('r' or 'u'). Such a string is
processed for interpolation after the normal interpretation of
backslash-escapes in its contents. The processing occurs just
before the string is pushed onto the value stack, each time the
string is pushed. In short, Python behaves exactly as if '$'
were a unary operator applied to the string. The operation
performed is as follows:
Strings may be preceded with a '$' prefix that comes before the
leading single or double quotation mark (or triplet) and before
any of the other string prefixes ('r' or 'u'). Such a string is
processed for interpolation after the normal interpretation of
backslash-escapes in its contents. The processing occurs just
before the string is pushed onto the value stack, each time the
string is pushed. In short, Python behaves exactly as if '$'
were a unary operator applied to the string. The operation
performed is as follows:
The string is scanned from start to end for the '$' character
(\x24 in 8-bit strings or \u0024 in Unicode strings). If there
are no '$' characters present, the string is returned unchanged.
The string is scanned from start to end for the '$' character
(``\x24`` in 8-bit strings or ``\u0024`` in Unicode strings). If there
are no '$' characters present, the string is returned unchanged.
Any '$' found in the string, followed by one of the two kinds of
expressions described below, is replaced with the value of the
expression as evaluated in the current namespaces. The value is
converted with str() if the containing string is an 8-bit string,
or with unicode() if it is a Unicode string.
Any '$' found in the string, followed by one of the two kinds of
expressions described below, is replaced with the value of the
expression as evaluated in the current namespaces. The value is
converted with ``str()`` if the containing string is an 8-bit string,
or with ``unicode()`` if it is a Unicode string.
1. A Python identifier optionally followed by any number of
1. A Python identifier optionally followed by any number of
trailers, where a trailer consists of:
- a dot and an identifier,
- an expression enclosed in square brackets, or
- an argument list enclosed in parentheses
(This is exactly the pattern expressed in the Python grammar
by "NAME trailer*", using the definitions in Grammar/Grammar.)
by "``NAME`` trailer*", using the definitions in Grammar/Grammar.)
2. Any complete Python expression enclosed in curly braces.
2. Any complete Python expression enclosed in curly braces.
Two dollar-signs ("$$") are replaced with a single "$".
Two dollar-signs ("$$") are replaced with a single "$".
Examples
========
Here is an example of an interactive session exhibiting the
expected behaviour of this feature.
Here is an example of an interactive session exhibiting the
expected behaviour of this feature::
>>> a, b = 5, 6
>>> print $'a = $a, b = $b'
@ -88,56 +94,65 @@ Examples
Discussion
==========
'$' is chosen as the interpolation character within the
string for the sake of familiarity, since it is already used
for this purpose in many other languages and contexts.
'$' is chosen as the interpolation character within the
string for the sake of familiarity, since it is already used
for this purpose in many other languages and contexts.
It is then natural to choose '$' as a prefix, since it is a
mnemonic for the interpolation character.
It is then natural to choose '$' as a prefix, since it is a
mnemonic for the interpolation character.
Trailers are permitted to give this interpolation mechanism
even more power than the interpolation available in most other
languages, while the expression to be interpolated remains
clearly visible and free of curly braces.
Trailers are permitted to give this interpolation mechanism
even more power than the interpolation available in most other
languages, while the expression to be interpolated remains
clearly visible and free of curly braces.
'$' works like an operator and could be implemented as an
operator, but that prevents the compile-time optimization
and presents security issues. So, it is only allowed as a
string prefix.
'$' works like an operator and could be implemented as an
operator, but that prevents the compile-time optimization
and presents security issues. So, it is only allowed as a
string prefix.
Security Issues
===============
"$" has the power to eval, but only to eval a literal. As
described here (a string prefix rather than an operator), it
introduces no new security issues since the expressions to be
evaluated must be literally present in the code.
"$" has the power to eval, but only to eval a literal. As
described here (a string prefix rather than an operator), it
introduces no new security issues since the expressions to be
evaluated must be literally present in the code.
Implementation
==============
The Itpl module at http://www.lfw.org/python/Itpl.py provides a
prototype of this feature. It uses the tokenize module to find
the end of an expression to be interpolated, then calls eval()
on the expression each time a value is needed. In the prototype,
the expression is parsed and compiled again each time it is
evaluated.
The ``Itpl`` module at [1]_ provides a
prototype of this feature. It uses the tokenize module to find
the end of an expression to be interpolated, then calls ``eval()``
on the expression each time a value is needed. In the prototype,
the expression is parsed and compiled again each time it is
evaluated.
As an optimization, interpolated strings could be compiled
directly into the corresponding bytecode; that is,
As an optimization, interpolated strings could be compiled
directly into the corresponding bytecode; that is::
$'a = $a, b = $b'
could be compiled as though it were the expression
could be compiled as though it were the expression::
('a = ' + str(a) + ', b = ' + str(b))
so that it only needs to be compiled once.
so that it only needs to be compiled once.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
References
==========
.. [1] http://www.lfw.org/python/Itpl.py
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:

155
pep-0226.txt
View File

@ -5,121 +5,132 @@ Last-Modified: $Date$
Author: Jeremy Hylton <jeremy@alum.mit.edu>
Status: Final
Type: Informational
Content-Type: text/x-rst
Created: 16-Oct-2000
Python-Version: 2.1
Post-History:
Abstract
This document describes the post Python 2.0 development and
release schedule. According to this schedule, Python 2.1 will be
released in April of 2001. The schedule primarily concerns
itself with PEP-size items. Small bug fixes and changes will
occur up until the first beta release.
Abstract
========
This document describes the post Python 2.0 development and
release schedule. According to this schedule, Python 2.1 will be
released in April of 2001. The schedule primarily concerns
itself with PEP-size items. Small bug fixes and changes will
occur up until the first beta release.
Release Schedule
================
Tentative future release dates
Tentative future release dates
[bugfix release dates go here]
[bugfix release dates go here]
Past release dates:
Past release dates:
- 17-Apr-2001: 2.1 final release
- 15-Apr-2001: 2.1 release candidate 2
- 13-Apr-2001: 2.1 release candidate 1
- 23-Mar-2001: Python 2.1 beta 2 release
- 02-Mar-2001: First 2.1 beta release
- 02-Feb-2001: Python 2.1 alpha 2 release
- 22-Jan-2001: Python 2.1 alpha 1 release
- 16-Oct-2000: Python 2.0 final release
17-Apr-2001: 2.1 final release
15-Apr-2001: 2.1 release candidate 2
13-Apr-2001: 2.1 release candidate 1
23-Mar-2001: Python 2.1 beta 2 release
02-Mar-2001: First 2.1 beta release
02-Feb-2001: Python 2.1 alpha 2 release
22-Jan-2001: Python 2.1 alpha 1 release
16-Oct-2000: Python 2.0 final release
Open issues for Python 2.0 beta 2
=================================
Add a default unit testing framework to the standard library.
Add a default unit testing framework to the standard library.
Guidelines for making changes for Python 2.1
============================================
The guidelines and schedule will be revised based on discussion in
the python-dev@python.org mailing list.
The guidelines and schedule will be revised based on discussion in
the python-dev@python.org mailing list.
The PEP system was instituted late in the Python 2.0 development
cycle and many changes did not follow the process described in PEP
1. The development process for 2.1, however, will follow the PEP
process as documented.
The PEP system was instituted late in the Python 2.0 development
cycle and many changes did not follow the process described in PEP 1.
The development process for 2.1, however, will follow the PEP
process as documented.
The first eight weeks following 2.0 final will be the design and
review phase. By the end of this period, any PEP that is proposed
for 2.1 should be ready for review. This means that the PEP is
written and discussion has occurred on the python-dev@python.org
and python-list@python.org mailing lists.
The first eight weeks following 2.0 final will be the design and
review phase. By the end of this period, any PEP that is proposed
for 2.1 should be ready for review. This means that the PEP is
written and discussion has occurred on the python-dev@python.org
and python-list@python.org mailing lists.
The next six weeks will be spent reviewing the PEPs and
implementing and testing the accepted PEPs. When this period
stops, we will end consideration of any incomplete PEPs. Near the
end of this period, there will be a feature freeze where any small
features not worthy of a PEP will not be accepted.
The next six weeks will be spent reviewing the PEPs and
implementing and testing the accepted PEPs. When this period
stops, we will end consideration of any incomplete PEPs. Near the
end of this period, there will be a feature freeze where any small
features not worthy of a PEP will not be accepted.
Before the final release, we will have six weeks of beta testing
and a release candidate or two.
Before the final release, we will have six weeks of beta testing
and a release candidate or two.
General guidelines for submitting patches and making changes
============================================================
Use good sense when committing changes. You should know what we
mean by good sense or we wouldn't have given you commit privileges
<0.5 wink>. Some specific examples of good sense include:
Use good sense when committing changes. You should know what we
mean by good sense or we wouldn't have given you commit privileges
<0.5 wink>. Some specific examples of good sense include:
- Do whatever the dictator tells you.
- Do whatever the dictator tells you.
- Discuss any controversial changes on python-dev first. If you
- Discuss any controversial changes on python-dev first. If you
get a lot of +1 votes and no -1 votes, make the change. If you
get a some -1 votes, think twice; consider asking Guido what he
thinks.
- If the change is to code you contributed, it probably makes
- If the change is to code you contributed, it probably makes
sense for you to fix it.
- If the change affects code someone else wrote, it probably makes
- If the change affects code someone else wrote, it probably makes
sense to ask him or her first.
- You can use the SourceForge (SF) Patch Manager to submit a patch
- You can use the SourceForge (SF) Patch Manager to submit a patch
and assign it to someone for review.
Any significant new feature must be described in a PEP and
approved before it is checked in.
Any significant new feature must be described in a PEP and
approved before it is checked in.
Any significant code addition, such as a new module or large
patch, must include test cases for the regression test and
documentation. A patch should not be checked in until the tests
and documentation are ready.
Any significant code addition, such as a new module or large
patch, must include test cases for the regression test and
documentation. A patch should not be checked in until the tests
and documentation are ready.
If you fix a bug, you should write a test case that would have
caught the bug.
If you fix a bug, you should write a test case that would have
caught the bug.
If you commit a patch from the SF Patch Manager or fix a bug from
the Jitterbug database, be sure to reference the patch/bug number
in the CVS log message. Also be sure to change the status in the
patch manager or bug database (if you have access to the bug
database).
If you commit a patch from the SF Patch Manager or fix a bug from
the Jitterbug database, be sure to reference the patch/bug number
in the CVS log message. Also be sure to change the status in the
patch manager or bug database (if you have access to the bug
database).
It is not acceptable for any checked in code to cause the
regression test to fail. If a checkin causes a failure, it must
be fixed within 24 hours or it will be backed out.
It is not acceptable for any checked in code to cause the
regression test to fail. If a checkin causes a failure, it must
be fixed within 24 hours or it will be backed out.
All contributed C code must be ANSI C. If possible check it with
two different compilers, e.g. gcc and MSVC.
All contributed C code must be ANSI C. If possible check it with
two different compilers, e.g. gcc and MSVC.
All contributed Python code must follow Guido's Python style
guide. http://www.python.org/doc/essays/styleguide.html
All contributed Python code must follow Guido's Python style
guide. http://www.python.org/doc/essays/styleguide.html
It is understood that any code contributed will be released under
an Open Source license. Do not contribute code if it can't be
released this way.
It is understood that any code contributed will be released under
an Open Source license. Do not contribute code if it can't be
released this way.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:

114
pep-0239.txt
View File

@ -2,94 +2,102 @@ PEP: 239
Title: Adding a Rational Type to Python
Version: $Revision$
Last-Modified: $Date$
Author: Christopher A. Craig <python-pep@ccraig.org>,
Moshe Zadka <moshez@zadka.site.co.il>
Author: Christopher A. Craig <python-pep@ccraig.org>, Moshe Zadka <moshez@zadka.site.co.il>
Status: Rejected
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Mar-2001
Python-Version: 2.2
Post-History: 16-Mar-2001
Abstract
========
Python has no numeric type with the semantics of an unboundedly
precise rational number. This proposal explains the semantics of
such a type, and suggests builtin functions and literals to
support such a type. This PEP suggests no literals for rational
numbers; that is left for another PEP [1]_.
Python has no numeric type with the semantics of an unboundedly
precise rational number. This proposal explains the semantics of
such a type, and suggests builtin functions and literals to
support such a type. This PEP suggests no literals for rational
numbers; that is left for another PEP[1].
BDFL Pronouncement
==================
This PEP is rejected. The needs outlined in the rationale section
have been addressed to some extent by the acceptance of PEP 327
for decimal arithmetic. Guido also noted, "Rational arithmetic
was the default 'exact' arithmetic in ABC and it did not work out as
expected". See the python-dev discussion on 17 June 2005.
This PEP is rejected. The needs outlined in the rationale section
have been addressed to some extent by the acceptance of PEP 327
for decimal arithmetic. Guido also noted, "Rational arithmetic
was the default 'exact' arithmetic in ABC and it did not work out as
expected". See the python-dev discussion on 17 June 2005 [2]_.
*Postscript:* With the acceptance of PEP 3141, "A Type Hierarchy
for Numbers", a 'Rational' numeric abstract base class was added
with a concrete implementation in the 'fractions' module.
*Postscript:* With the acceptance of PEP 3141, "A Type Hierarchy
for Numbers", a 'Rational' numeric abstract base class was added
with a concrete implementation in the 'fractions' module.
Rationale
=========
While sometimes slower and more memory intensive (in general,
unboundedly so) rational arithmetic captures more closely the
mathematical ideal of numbers, and tends to have behavior which is
less surprising to newbies. Though many Python implementations of
rational numbers have been written, none of these exist in the
core, or are documented in any way. This has made them much less
accessible to people who are less Python-savvy.
While sometimes slower and more memory intensive (in general,
unboundedly so) rational arithmetic captures more closely the
mathematical ideal of numbers, and tends to have behavior which is
less surprising to newbies. Though many Python implementations of
rational numbers have been written, none of these exist in the
core, or are documented in any way. This has made them much less
accessible to people who are less Python-savvy.
RationalType
============
There will be a new numeric type added called RationalType. Its
unary operators will do the obvious thing. Binary operators will
coerce integers and long integers to rationals, and rationals to
floats and complexes.
There will be a new numeric type added called ``RationalType``. Its
unary operators will do the obvious thing. Binary operators will
coerce integers and long integers to rationals, and rationals to
floats and complexes.
The following attributes will be supported: .numerator and
.denominator. The language definition will promise that
The following attributes will be supported: ``.numerator`` and
``.denominator``. The language definition will promise that::
r.denominator * r == r.numerator
that the GCD of the numerator and the denominator is 1 and that
the denominator is positive.
that the GCD of the numerator and the denominator is 1 and that
the denominator is positive.
The method r.trim(max_denominator) will return the closest
rational s to r such that abs(s.denominator) <= max_denominator.
The method ``r.trim(max_denominator)`` will return the closest
rational ``s`` to ``r`` such that ``abs(s.denominator) <= max_denominator``.
The rational() Builtin
======================
This function will have the signature rational(n, d=1). n and d
must both be integers, long integers or rationals. A guarantee is
made that
This function will have the signature ``rational(n, d=1)``. ``n`` and ``d``
must both be integers, long integers or rationals. A guarantee is
made that::
rational(n, d) * d == n
Open Issues
===========
- Maybe the type should be called rat instead of rational.
- Maybe the type should be called rat instead of rational.
Somebody proposed that we have "abstract" pure mathematical
types named complex, real, rational, integer, and "concrete"
representation types with names like float, rat, long, int.
- Should a rational number with an integer value be allowed as a
sequence index? For example, should s[5/3 - 2/3] be equivalent
to s[1]?
- Should a rational number with an integer value be allowed as a
sequence index? For example, should ``s[5/3 - 2/3]`` be equivalent
to ``s[1]``?
- Should shift and mask operators be allowed for rational numbers?
- Should ``shift`` and ``mask`` operators be allowed for rational numbers?
For rational numbers with integer values?
- Marcin 'Qrczak' Kowalczyk summarized the arguments for and
against unifying ints with rationals nicely on c.l.py:
- Marcin 'Qrczak' Kowalczyk summarized the arguments for and
against unifying ints with rationals nicely on c.l.py
Arguments for unifying ints with rationals:
- Since 2 == 2/1 and maybe str(2/1) == '2', it reduces surprises
- Since ``2 == 2/1`` and maybe ``str(2/1) == '2'``, it reduces surprises
where objects seem equal but behave differently.
- / can be freely used for integer division when I *know* that
@ -117,18 +125,24 @@ Open Issues
References
==========
[1] PEP 240, Adding a Rational Literal to Python, Zadka,
.. [1] PEP 240, Adding a Rational Literal to Python, Zadka,
http://www.python.org/dev/peps/pep-0240/
.. [2] Raymond Hettinger, Propose rejection of PEPs 239 and 240 -- a builtin
rational type and rational literals
https://mail.python.org/pipermail/python-dev/2005-June/054281.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:

126
pep-0250.txt
View File

@ -5,57 +5,61 @@ Last-Modified: $Date$
Author: p.f.moore@gmail.com (Paul Moore)
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Mar-2001
Python-Version: 2.2
Post-History: 30-Mar-2001
Abstract
========
The standard Python distribution includes a directory
Lib/site-packages, which is used on Unix platforms to hold
locally-installed modules and packages. The site.py module
distributed with Python includes support for locating other
modules in the site-packages directory.
The standard Python distribution includes a directory
``Lib/site-packages``, which is used on Unix platforms to hold
locally-installed modules and packages. The ``site.py`` module
distributed with Python includes support for locating other
modules in the site-packages directory.
This PEP proposes that the site-packages directory should be used
on the Windows platform in a similar manner.
This PEP proposes that the site-packages directory should be used
on the Windows platform in a similar manner.
Motivation
==========
On Windows platforms, the default setting for sys.path does not
include a directory suitable for users to install locally
developed modules. The "expected" location appears to be the
directory containing the Python executable itself. This is also
the location where distutils (and distutils-generated installers)
installs packages. Including locally developed code in the same
directory as installed executables is not good practice.
On Windows platforms, the default setting for ``sys.path`` does not
include a directory suitable for users to install locally
developed modules. The "expected" location appears to be the
directory containing the Python executable itself. This is also
the location where distutils (and distutils-generated installers)
installs packages. Including locally developed code in the same
directory as installed executables is not good practice.
Clearly, users can manipulate sys.path, either in a locally
modified site.py, or in a suitable sitecustomize.py, or even via
.pth files. However, there should be a standard location for such
files, rather than relying on every individual site having to set
their own policy.
Clearly, users can manipulate ``sys.path``, either in a locally
modified ``site.py``, or in a suitable ``sitecustomize.py``, or even via
``.pth`` files. However, there should be a standard location for such
files, rather than relying on every individual site having to set
their own policy.
In addition, with distutils becoming more prevalent as a means of
distributing modules, the need for a standard install location for
distributed modules will become more common. It would be better
to define such a standard now, rather than later when more
distutils-based packages exist which will need rebuilding.
In addition, with distutils becoming more prevalent as a means of
distributing modules, the need for a standard install location for
distributed modules will become more common. It would be better
to define such a standard now, rather than later when more
distutils-based packages exist which will need rebuilding.
It is relevant to note that prior to Python 2.1, the site-packages
directory was not included in sys.path for Macintosh platforms.
This has been changed in 2.1, and Macintosh includes sys.path now,
leaving Windows as the only major platform with no site-specific
modules directory.
It is relevant to note that prior to Python 2.1, the site-packages
directory was not included in ``sys.path`` for Macintosh platforms.
This has been changed in 2.1, and Macintosh includes ``sys.path`` now,
leaving Windows as the only major platform with no site-specific
modules directory.
Implementation
==============
The implementation of this feature is fairly trivial. All that
would be required is a change to site.py, to change the section
setting sitedirs. The Python 2.1 version has
The implementation of this feature is fairly trivial. All that
would be required is a change to ``site.py``, to change the section
setting sitedirs. The Python 2.1 version has::
if os.sep == '/':
sitedirs = [makepath(prefix,
@ -68,44 +72,45 @@ Implementation
else:
sitedirs = [prefix]
A suitable change would be to simply replace the last 4 lines with
A suitable change would be to simply replace the last 4 lines with::
else:
sitedirs == [prefix, makepath(prefix, "lib", "site-packages")]
Changes would also be required to distutils, to reflect this change
in policy. A patch is available on Sourceforge, patch ID 445744,
which implements this change. Note that the patch checks the Python
version and only invokes the new behaviour for Python versions from
2.2 onwards. This is to ensure that distutils remains compatible
with earlier versions of Python.
Changes would also be required to distutils, to reflect this change
in policy. A patch is available on Sourceforge, patch ID 445744,
which implements this change. Note that the patch checks the Python
version and only invokes the new behaviour for Python versions from
2.2 onwards. This is to ensure that distutils remains compatible
with earlier versions of Python.
Finally, the executable code which implements the Windows installer
used by the bdist_wininst command will need changing to use the new
location. A separate patch is available for this, currently
maintained by Thomas Heller.
Finally, the executable code which implements the Windows installer
used by the ``bdist_wininst`` command will need changing to use the new
location. A separate patch is available for this, currently
maintained by Thomas Heller.
Notes
=====
- This change does not preclude packages using the current
location -- the change only adds a directory to sys.path, it
- This change does not preclude packages using the current
location -- the change only adds a directory to ``sys.path``, it
does not remove anything.
- Both the current location (sys.prefix) and the new directory
(site-packages) are included in sitedirs, so that .pth files
- Both the current location (``sys.prefix``) and the new directory
(site-packages) are included in sitedirs, so that ``.pth`` files
will be recognised in either location.
- This proposal adds a single additional site-packages directory
- This proposal adds a single additional site-packages directory
to sitedirs. On Unix platforms, two directories are added, one
for version-independent files (Python code) and one for
version-dependent code (C extensions). This is necessary on
Unix, as the sitedirs include a common (across Python versions)
package location, in /usr/local by default. As there is no such
package location, in ``/usr/local`` by default. As there is no such
common location available on Windows, there is also no need for
having two separate package directories.
- If users want to keep DLLs in a single location on Windows, rather
- If users want to keep DLLs in a single location on Windows, rather
than keeping them in the package directory, the DLLs subdirectory
of the Python install directory is already available for that
purpose. Adding an extra directory solely for DLLs should not be
@ -113,26 +118,29 @@ Notes
Open Issues
===========
- Comments from Unix users indicate that there may be issues with
- Comments from Unix users indicate that there may be issues with
the current setup on the Unix platform. Rather than become
involved in cross-platform issues, this PEP specifically limits
itself to the Windows platform, leaving changes for other platforms
to be covered inother PEPs.
to be covered in other PEPs.
- There could be issues with applications which embed Python. To the
- There could be issues with applications which embed Python. To the
author's knowledge, there should be no problem as a result of this
change. There have been no comments (supportive or otherwise) from
users who embed Python.
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:

117
pep-0259.txt
View File

@ -5,30 +5,34 @@ Last-Modified: $Date$
Author: guido@python.org (Guido van Rossum)
Status: Rejected
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Jun-2001
Python-Version: 2.2
Post-History: 11-Jun-2001
Abstract
========
Currently, the print statement always appends a newline, unless a
trailing comma is used. This means that if we want to print data
that already ends in a newline, we get two newlines, unless
special precautions are taken.
Currently, the ``print`` statement always appends a newline, unless a
trailing comma is used. This means that if we want to print data
that already ends in a newline, we get two newlines, unless
special precautions are taken.
I propose to skip printing the newline when it follows a newline
that came from data.
I propose to skip printing the newline when it follows a newline
that came from data.
In order to avoid having to add yet another magic variable to file
objects, I propose to give the existing 'softspace' variable an
extra meaning: a negative value will mean "the last data written
ended in a newline so no space *or* newline is required."
In order to avoid having to add yet another magic variable to file
objects, I propose to give the existing 'softspace' variable an
extra meaning: a negative value will mean "the last data written
ended in a newline so no space *or* newline is required."
Problem
=======
When printing data that resembles the lines read from a file using
a simple loop, double-spacing occurs unless special care is taken:
When printing data that resembles the lines read from a file using
a simple loop, double-spacing occurs unless special care is taken::
>>> for line in open("/etc/passwd").readlines():
... print line
@ -43,91 +47,98 @@ Problem
>>>
While there are easy work-arounds, this is often noticed only
during testing and requires an extra edit-test roundtrip; the
fixed code is uglier and harder to maintain.
While there are easy work-arounds, this is often noticed only
during testing and requires an extra edit-test roundtrip; the
fixed code is uglier and harder to maintain.
Proposed Solution
=================
In the PRINT_ITEM opcode in ceval.c, when a string object is
printed, a check is already made that looks at the last character
of that string. Currently, if that last character is a whitespace
character other than space, the softspace flag is reset to zero;
this suppresses the space between two items if the first item is a
string ending in newline, tab, etc. (but not when it ends in a
space). Otherwise the softspace flag is set to one.
In the ``PRINT_ITEM`` opcode in ``ceval.c``, when a string object is
printed, a check is already made that looks at the last character
of that string. Currently, if that last character is a whitespace
character other than space, the softspace flag is reset to zero;
this suppresses the space between two items if the first item is a
string ending in newline, tab, etc. (but not when it ends in a
space). Otherwise the softspace flag is set to one.
The proposal changes this test slightly so that softspace is set
to:
The proposal changes this test slightly so that softspace is set
to:
-1 -- if the last object written is a string ending in a
- ``-1`` -- if the last object written is a string ending in a
newline
0 -- if the last object written is a string ending in a
- ``0`` -- if the last object written is a string ending in a
whitespace character that's neither space nor newline
1 -- in all other cases (including the case when the last
- ``1`` -- in all other cases (including the case when the last
object written is an empty string or not a string)
Then, the PRINT_NEWLINE opcode, printing of the newline is
suppressed if the value of softspace is negative; in any case the
softspace flag is reset to zero.
Then, the ``PRINT_NEWLINE`` opcode, printing of the newline is
suppressed if the value of softspace is negative; in any case the
softspace flag is reset to zero.
Scope
=====
This only affects printing of 8-bit strings. It doesn't affect
Unicode, although that could be considered a bug in the Unicode
implementation. It doesn't affect other objects whose string
representation happens to end in a newline character.
This only affects printing of 8-bit strings. It doesn't affect
Unicode, although that could be considered a bug in the Unicode
implementation. It doesn't affect other objects whose string
representation happens to end in a newline character.
Risks
=====
This change breaks some existing code. For example:
This change breaks some existing code. For example::
print "Subject: PEP 259\n"
print message_body
In current Python, this produces a blank line separating the
subject from the message body; with the proposed change, the body
begins immediately below the subject. This is not very robust
code anyway; it is better written as
In current Python, this produces a blank line separating the
subject from the message body; with the proposed change, the body
begins immediately below the subject. This is not very robust
code anyway; it is better written as::
print "Subject: PEP 259"
print
print message_body
In the test suite, only test_StringIO (which explicitly tests for
this feature) breaks.
In the test suite, only ``test_StringIO`` (which explicitly tests for
this feature) breaks.
Implementation
==============
A patch relative to current CVS is here:
A patch relative to current CVS is here::
http://sourceforge.net/tracker/index.php?func=detail&aid=432183&group_id=5470&atid=305470
Rejected
========
The user community unanimously rejected this, so I won't pursue
this idea any further. Frequently heard arguments against
included:
The user community unanimously rejected this, so I won't pursue
this idea any further. Frequently heard arguments against
included:
- It is likely to break thousands of CGI scripts.
- It is likely to break thousands of CGI scripts.
- Enough magic already (also: no more tinkering with 'print'
- Enough magic already (also: no more tinkering with 'print'
please).
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:

164
pep-0264.txt
View File

@ -5,6 +5,7 @@ Last-Modified: $Date$
Author: Michael Hudson <mwh@python.net>
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Requires: 236
Created: 30-Jul-2001
Python-Version: 2.2
@ -12,129 +13,140 @@ Post-History: 30-Jul-2001
Abstract
========
As noted in PEP 236, there is no clear way for "simulated
interactive shells" to simulate the behaviour of __future__
statements in "real" interactive shells, i.e. have __future__
statements' effects last the life of the shell.
As noted in PEP 236, there is no clear way for "simulated
interactive shells" to simulate the behaviour of ``__future__``
statements in "real" interactive shells, i.e. have ``__future__``
statements' effects last the life of the shell.
The PEP also takes the opportunity to clean up the other
unresolved issue mentioned in PEP 236, the inability to stop
compile() inheriting the effect of future statements affecting the
code calling compile().
The PEP also takes the opportunity to clean up the other
unresolved issue mentioned in PEP 236, the inability to stop
``compile()`` inheriting the effect of future statements affecting the
code calling ``compile()``.
This PEP proposes to address the first problem by adding an
optional fourth argument to the builtin function "compile", adding
information to the _Feature instances defined in __future__.py and
adding machinery to the standard library modules "codeop" and
"code" to make the construction of such shells easy.
This PEP proposes to address the first problem by adding an
optional fourth argument to the builtin function "compile", adding
information to the ``_Feature`` instances defined in ``__future__.py`` and
adding machinery to the standard library modules "codeop" and
"code" to make the construction of such shells easy.
The second problem is dealt with by simply adding *another*
optional argument to compile(), which if non-zero suppresses the
inheriting of future statements' effects.
The second problem is dealt with by simply adding *another*
optional argument to ``compile()``, which if non-zero suppresses the
inheriting of future statements' effects.
Specification
=============
I propose adding a fourth, optional, "flags" argument to the
builtin "compile" function. If this argument is omitted,
there will be no change in behaviour from that of Python 2.1.
I propose adding a fourth, optional, "flags" argument to the
builtin "compile" function. If this argument is omitted,
there will be no change in behaviour from that of Python 2.1.
If it is present it is expected to be an integer, representing
various possible compile time options as a bitfield. The
bitfields will have the same values as the CO_* flags already used
by the C part of Python interpreter to refer to future statements.
If it is present it is expected to be an integer, representing
various possible compile time options as a bitfield. The
bitfields will have the same values as the ``CO_*`` flags already used
by the C part of Python interpreter to refer to future statements.
compile() shall raise a ValueError exception if it does not
recognize any of the bits set in the supplied flags.
``compile()`` shall raise a ``ValueError`` exception if it does not
recognize any of the bits set in the supplied flags.
The flags supplied will be bitwise-"or"ed with the flags that
would be set anyway, unless the new fifth optional argument is a
non-zero intger, in which case the flags supplied will be exactly
the set used.
The flags supplied will be bitwise-"or"ed with the flags that
would be set anyway, unless the new fifth optional argument is a
non-zero intger, in which case the flags supplied will be exactly
the set used.
The above-mentioned flags are not currently exposed to Python. I
propose adding .compiler_flag attributes to the _Feature objects
in __future__.py that contain the necessary bits, so one might
write code such as:
The above-mentioned flags are not currently exposed to Python. I
propose adding ``.compiler_flag`` attributes to the ``_Feature`` objects
in ``__future__.py`` that contain the necessary bits, so one might
write code such as::
import __future__
def compile_generator(func_def):
return compile(func_def, "<input>", "suite",
__future__.generators.compiler_flag)
A recent change means that these same bits can be used to tell if
a code object was compiled with a given feature; for instance
A recent change means that these same bits can be used to tell if
a code object was compiled with a given feature; for instance::
codeob.co_flags & __future__.generators.compiler_flag
codeob.co_flags & __future__.generators.compiler_flag``
will be non-zero if and only if the code object "codeob" was
compiled in an environment where generators were allowed.
will be non-zero if and only if the code object "codeob" was
compiled in an environment where generators were allowed.
I will also add a .all_feature_flags attribute to the __future__
module, giving a low-effort way of enumerating all the __future__
options supported by the running interpreter.
I will also add a ``.all_feature_flags`` attribute to the ``__future__``
module, giving a low-effort way of enumerating all the ``__future__``
options supported by the running interpreter.
I also propose adding a pair of classes to the standard library
module codeop.
I also propose adding a pair of classes to the standard library
module codeop.
One - Compile - will sport a __call__ method which will act much
like the builtin "compile" of 2.1 with the difference that after
it has compiled a __future__ statement, it "remembers" it and
compiles all subsequent code with the __future__ option in effect.
One - Compile - will sport a ``__call__`` method which will act much
like the builtin "compile" of 2.1 with the difference that after
it has compiled a ``__future__`` statement, it "remembers" it and
compiles all subsequent code with the ``__future__`` option in effect.
It will do this by using the new features of the __future__ module
mentioned above.
It will do this by using the new features of the ``__future__`` module
mentioned above.
Objects of the other class added to codeop - CommandCompiler -
will do the job of the existing codeop.compile_command function,
but in a __future__-aware way.
Objects of the other class added to codeop - ``CommandCompiler`` -
will do the job of the existing ``codeop.compile_command`` function,
but in a ``__future__``-aware way.
Finally, I propose to modify the class InteractiveInterpreter in
the standard library module code to use a CommandCompiler to
emulate still more closely the behaviour of the default Python
shell.
Finally, I propose to modify the class ``InteractiveInterpreter`` in
the standard library module code to use a ``CommandCompiler`` to
emulate still more closely the behaviour of the default Python
shell.
Backward Compatibility
======================
Should be very few or none; the changes to compile will make no
difference to existing code, nor will adding new functions or
classes to codeop. Existing code using
code.InteractiveInterpreter may change in behaviour, but only for
the better in that the "real" Python shell will be being better
impersonated.
Should be very few or none; the changes to compile will make no
difference to existing code, nor will adding new functions or
classes to codeop. Existing code using
``code.InteractiveInterpreter`` may change in behaviour, but only for
the better in that the "real" Python shell will be being better
impersonated.
Forward Compatibility
=====================
The fiddling that needs to be done to Lib/__future__.py when
adding a __future_ feature will be a touch more complicated.
Everything else should just work.
The fiddling that needs to be done to ``Lib/__future__.py`` when
adding a ``__future__`` feature will be a touch more complicated.
Everything else should just work.
Issues
======
I hope the above interface is not too disruptive to implement for
Jython.
I hope the above interface is not too disruptive to implement for
Jython.
Implementation
==============
A series of preliminary implementations are at:
A series of preliminary implementations are at [1]_.
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470
After light massaging by Tim Peters, they have now been checked in.
After light massaging by Tim Peters, they have now been checked in.
References
==========
.. [1] http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&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
End:
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:

157
pep-0274.txt
View File

@ -5,131 +5,138 @@ Last-Modified: $Date$
Author: Barry Warsaw <barry@python.org>
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 25-Oct-2001
Python-Version: 2.7, 3.0 (originally 2.3)
Post-History: 29-Oct-2001
Abstract
========
PEP 202 introduces a syntactical extension to Python called the
"list comprehension"[1]. This PEP proposes a similar syntactical
extension called the "dictionary comprehension" or "dict
comprehension" for short. You can use dict comprehensions in ways
very similar to list comprehensions, except that they produce
Python dictionary objects instead of list objects.
PEP 202 introduces a syntactical extension to Python called the
"list comprehension". This PEP proposes a similar syntactical
extension called the "dictionary comprehension" or "dict
comprehension" for short. You can use dict comprehensions in ways
very similar to list comprehensions, except that they produce
Python dictionary objects instead of list objects.
Resolution
==========
This PEP was originally written for inclusion in Python 2.3. It
was withdrawn after observation that substantially all of its
benefits were subsumed by generator expressions coupled with the
dict() constructor.
This PEP was originally written for inclusion in Python 2.3. It
was withdrawn after observation that substantially all of its
benefits were subsumed by generator expressions coupled with the
``dict()`` constructor.
However, Python 2.7 and 3.0 introduces this exact feature, as well
as the closely related set comprehensions. On 2012-04-09, the PEP
was changed to reflect this reality by updating its Status to
Accepted, and updating the Python-Version field. The Open
Questions section was also removed since these have been long
resolved by the current implementation.
However, Python 2.7 and 3.0 introduces this exact feature, as well
as the closely related set comprehensions. On 2012-04-09, the PEP
was changed to reflect this reality by updating its Status to
Accepted, and updating the Python-Version field. The Open
Questions section was also removed since these have been long
resolved by the current implementation.
Proposed Solution
=================
Dict comprehensions are just like list comprehensions, except that
you group the expression using curly braces instead of square
braces. Also, the left part before the `for' keyword expresses
both a key and a value, separated by a colon. The notation is
specifically designed to remind you of list comprehensions as
applied to dictionaries.
Dict comprehensions are just like list comprehensions, except that
you group the expression using curly braces instead of square
braces. Also, the left part before the ``for`` keyword expresses
both a key and a value, separated by a colon. The notation is
specifically designed to remind you of list comprehensions as
applied to dictionaries.
Rationale
=========
There are times when you have some data arranged as a sequences of
length-2 sequences, and you want to turn that into a dictionary.
In Python 2.2, the dict() constructor accepts an argument that is
a sequence of length-2 sequences, used as (key, value) pairs to
initialize a new dictionary object.
There are times when you have some data arranged as a sequences of
length-2 sequences, and you want to turn that into a dictionary.
In Python 2.2, the ``dict()`` constructor accepts an argument that is
a sequence of length-2 sequences, used as (key, value) pairs to
initialize a new dictionary object.
However, the act of turning some data into a sequence of length-2
sequences can be inconvenient or inefficient from a memory or
performance standpoint. Also, for some common operations, such as
turning a list of things into a set of things for quick duplicate
removal or set inclusion tests, a better syntax can help code
clarity.
However, the act of turning some data into a sequence of length-2
sequences can be inconvenient or inefficient from a memory or
performance standpoint. Also, for some common operations, such as
turning a list of things into a set of things for quick duplicate
removal or set inclusion tests, a better syntax can help code
clarity.
As with list comprehensions, an explicit for loop can always be
used (and in fact was the only way to do it in earlier versions of
Python). But as with list comprehensions, dict comprehensions can
provide a more syntactically succinct idiom that the traditional
for loop.
As with list comprehensions, an explicit for loop can always be
used (and in fact was the only way to do it in earlier versions of
Python). But as with list comprehensions, dict comprehensions can
provide a more syntactically succinct idiom that the traditional
for loop.
Semantics
=========
The semantics of dict comprehensions can actually be demonstrated
in stock Python 2.2, by passing a list comprehension to the
built-in dictionary constructor:
The semantics of dict comprehensions can actually be demonstrated
in stock Python 2.2, by passing a list comprehension to the
built-in dictionary constructor::
>>> dict([(i, chr(65+i)) for i in range(4)])
is semantically equivalent to
is semantically equivalent to::
>>> {i : chr(65+i) for i in range(4)}
The dictionary constructor approach has two distinct disadvantages
from the proposed syntax though. First, it isn't as legible as a
dict comprehension. Second, it forces the programmer to create an
in-core list object first, which could be expensive.
The dictionary constructor approach has two distinct disadvantages
from the proposed syntax though. First, it isn't as legible as a
dict comprehension. Second, it forces the programmer to create an
in-core list object first, which could be expensive.
Examples
========
>>> print {i : chr(65+i) for i in range(4)}
{0 : 'A', 1 : 'B', 2 : 'C', 3 : 'D'}
>>> print {k : v for k, v in someDict.iteritems()} == someDict.copy()
1
>>> print {x.lower() : 1 for x in list_of_email_addrs}
{'barry@zope.com' : 1, 'barry@python.org' : 1, 'guido@python.org' : 1}
>>> def invert(d):
... return {v : k for k, v in d.iteritems()}
...
>>> d = {0 : 'A', 1 : 'B', 2 : 'C', 3 : 'D'}
>>> print invert(d)
{'A' : 0, 'B' : 1, 'C' : 2, 'D' : 3}
>>> print {i : chr(65+i) for i in range(4)}
{0 : 'A', 1 : 'B', 2 : 'C', 3 : 'D'}
>>> {(k, v): k+v for k in range(4) for v in range(4)}
... {(3, 3): 6, (3, 2): 5, (3, 1): 4, (0, 1): 1, (2, 1): 3,
>>> print {k : v for k, v in someDict.iteritems()} == someDict.copy()
1
>>> print {x.lower() : 1 for x in list_of_email_addrs}
{'barry@zope.com' : 1, 'barry@python.org' : 1, 'guido@python.org' : 1}
>>> def invert(d):
... return {v : k for k, v in d.iteritems()}
...
>>> d = {0 : 'A', 1 : 'B', 2 : 'C', 3 : 'D'}
>>> print invert(d)
{'A' : 0, 'B' : 1, 'C' : 2, 'D' : 3}
>>> {(k, v): k+v for k in range(4) for v in range(4)}
... {(3, 3): 6, (3, 2): 5, (3, 1): 4, (0, 1): 1, (2, 1): 3,
(0, 2): 2, (3, 0): 3, (0, 3): 3, (1, 1): 2, (1, 0): 1,
(0, 0): 0, (1, 2): 3, (2, 0): 2, (1, 3): 4, (2, 2): 4, (
2, 3): 5}
Implementation
==============
All implementation details were resolved in the Python 2.7 and 3.0
time-frame.
References
[1] PEP 202, List Comprehensions
http://www.python.org/dev/peps/pep-0202/
All implementation details were resolved in the Python 2.7 and 3.0
time-frame.
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:

140
pep-0313.txt
View File

@ -5,124 +5,134 @@ Last-Modified: $Date$
Author: Mike Meyer <mwm@mired.org>
Status: Rejected
Type: Standards Track
Content-Type: text/plain
Content-Type: text/x-rst
Created: 01-Apr-2003
Python-Version: 2.4
Post-History:
Abstract
========
This PEP (also known as PEP CCCXIII) proposes adding Roman
numerals as a literal type. It also proposes the new built-in
function "roman", which converts an object to an integer, then
converts the integer to a string that is the Roman numeral literal
equivalent to the integer.
This PEP (also known as PEP CCCXIII) proposes adding Roman
numerals as a literal type. It also proposes the new built-in
function "roman", which converts an object to an integer, then
converts the integer to a string that is the Roman numeral literal
equivalent to the integer.
BDFL Pronouncement
==================
This PEP is rejected. While the majority of Python users deemed this
to be a nice-to-have feature, the community was unable to reach a
consensus on whether nine should be represented as IX, the modern
form, or VIIII, the classic form. Likewise, no agreement was
reached on whether MXM or MCMXC would be considered a well-formed
representation of 1990. A vocal minority of users has also requested
support for lower-cased numerals for use in (i) powerpoint slides,
(ii) academic work, and (iii) Perl documentation.
This PEP is rejected. While the majority of Python users deemed this
to be a nice-to-have feature, the community was unable to reach a
consensus on whether nine should be represented as IX, the modern
form, or VIIII, the classic form. Likewise, no agreement was
reached on whether MXM or MCMXC would be considered a well-formed
representation of 1990. A vocal minority of users has also requested
support for lower-cased numerals for use in (i) powerpoint slides,
(ii) academic work, and (iii) Perl documentation.
Rationale
=========
Roman numerals are used in a number of areas, and adding them to
Python as literals would make computations in those areas easier.
For instance, Super Bowls are counted with Roman numerals, and many
older movies have copyright dates in Roman numerals. Further,
LISP provides a Roman numerals literal package, so adding Roman
numerals to Python will help ease the LISP-envy sometimes seen in
comp.lang.python. Besides, the author thinks this is the easiest
way to get his name on a PEP.
Roman numerals are used in a number of areas, and adding them to
Python as literals would make computations in those areas easier.
For instance, Super Bowls are counted with Roman numerals, and many
older movies have copyright dates in Roman numerals. Further,
LISP provides a Roman numerals literal package, so adding Roman
numerals to Python will help ease the LISP-envy sometimes seen in
comp.lang.python. Besides, the author thinks this is the easiest
way to get his name on a PEP.
Syntax for Roman literals
=========================
Roman numeral literals will consist of the characters M, D, C, L,
X, V and I, and only those characters. They must be in upper
case, and represent an integer with the following rules:
Roman numeral literals will consist of the characters M, D, C, L,
X, V and I, and only those characters. They must be in upper
case, and represent an integer with the following rules:
1. Except as noted below, they must appear in the order M, D, C,
1. Except as noted below, they must appear in the order M, D, C,
L, X, V then I. Each occurrence of each character adds 1000, 500,
100, 50, 10, 5 and 1 to the value of the literal, respectively.
2. Only one D, V or L may appear in any given literal.
2. Only one D, V or L may appear in any given literal.
3. At most three each of Is, Xs and Cs may appear consecutively
3. At most three each of Is, Xs and Cs may appear consecutively
in any given literal.
4. A single I may appear immediately to the left of the single V,
4. A single I may appear immediately to the left of the single V,
followed by no Is, and adds 4 to the value of the literal.
5. A single I may likewise appear before the last X, followed by
5. A single I may likewise appear before the last X, followed by
no Is or Vs, and adds 9 to the value.
6. X is to L and C as I is to V and X, except the values are 40
6. X is to L and C as I is to V and X, except the values are 40
and 90, respectively.
7. C is to D and M as I is to V and X, except the values are 400
7. C is to D and M as I is to V and X, except the values are 400
and 900, respectively.
Any literal composed entirely of M, D, C, L, X, V and I characters
that does not follow this format will raise a syntax error,
because explicit is better than implicit.
Any literal composed entirely of M, D, C, L, X, V and I characters
that does not follow this format will raise a syntax error,
because explicit is better than implicit.
Built-In "roman" Function
=========================
The new built-in function "roman" will aide the translation from
integers to Roman numeral literals. It will accept a single
object as an argument, and return a string containing the literal
of the same value. If the argument is not an integer or a
rational (see PEP 239 [1]) it will passed through the existing
built-in "int" to obtain the value. This may cause a loss of
information if the object was a float. If the object is a
rational, then the result will be formatted as a rational literal
(see PEP 240 [2]) with the integers in the string being Roman
numeral literals.
The new built-in function "roman" will aide the translation from
integers to Roman numeral literals. It will accept a single
object as an argument, and return a string containing the literal
of the same value. If the argument is not an integer or a
rational (see PEP 239 [1]_) it will passed through the existing
built-in "int" to obtain the value. This may cause a loss of
information if the object was a float. If the object is a
rational, then the result will be formatted as a rational literal
(see PEP 240 [2]_) with the integers in the string being Roman
numeral literals.
Compatibility Issues
====================
No new keywords are introduced by this proposal. Programs that
use variable names that are all upper case and contain only the
characters M, D, C, L, X, V and I will be affected by the new
literals. These programs will now have syntax errors when those
variables are assigned, and either syntax errors or subtle bugs
when those variables are referenced in expressions. Since such
variable names violate PEP 8 [3], the code is already broken, it
just wasn't generating exceptions. This proposal corrects that
oversight in the language.
No new keywords are introduced by this proposal. Programs that
use variable names that are all upper case and contain only the
characters M, D, C, L, X, V and I will be affected by the new
literals. These programs will now have syntax errors when those
variables are assigned, and either syntax errors or subtle bugs
when those variables are referenced in expressions. Since such
variable names violate PEP 8 [3]_, the code is already broken, it
just wasn't generating exceptions. This proposal corrects that
oversight in the language.
References
==========
[1] PEP 239, Adding a Rational Type to Python
.. [1] PEP 239, Adding a Rational Type to Python
http://www.python.org/dev/peps/pep-0239/
[2] PEP 240, Adding a Rational Literal to Python
.. [2] PEP 240, Adding a Rational Literal to Python
http://www.python.org/dev/peps/pep-0240/
[3] PEP 8, Style Guide for Python Code
.. [3] PEP 8, Style Guide for Python Code
http://www.python.org/dev/peps/pep-0008/
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
End:
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:

68
pep-0336.txt
View File

@ -5,40 +5,45 @@ Last-Modified: $Date$
Author: Andrew McClelland <eternalsquire@comcast.net>
Status: Rejected
Type: Standards Track
Content-Type: text/plain
Content-Type: text/x-rst
Created: 28-Oct-2004
Post-History:
Abstract
========
``None`` should be a callable object that when called with any
arguments has no side effect and returns ``None``.
None should be a callable object that when called with any
arguments has no side effect and returns None.
BDFL Pronouncement
==================
This PEP is rejected. It is considered a feature that None raises
an error when called. The proposal falls short in tests for
obviousness, clarity, explictness, and necessity. The provided Switch
example is nice but easily handled by a simple lambda definition.
See python-dev discussion on 17 June 2005.
This PEP is rejected. It is considered a feature that ``None`` raises
an error when called. The proposal falls short in tests for
obviousness, clarity, explictness, and necessity. The provided Switch
example is nice but easily handled by a simple lambda definition.
See python-dev discussion on 17 June 2005 [2]_.
Motivation
==========
To allow a programming style for selectable actions that is more
in accordance with the minimalistic functional programming goals
of the Python language.
To allow a programming style for selectable actions that is more
in accordance with the minimalistic functional programming goals
of the Python language.
Rationale
=========
Allow the use of None in method tables as a universal no effect
rather than either (1) checking a method table entry against None
before calling, or (2) writing a local no effect method with
arguments similar to other functions in the table.
Allow the use of ``None`` in method tables as a universal no effect
rather than either (1) checking a method table entry against ``None``
before calling, or (2) writing a local no effect method with
arguments similar to other functions in the table.
The semantics would be effectively,
The semantics would be effectively::
class None:
@ -47,8 +52,9 @@ Rationale
How To Use
==========
Before, checking function table entry against None:
Before, checking function table entry against ``None``::
class Select:
@ -68,7 +74,7 @@ How To Use
}.get(input, None)
if function: return function(input)
Before, using a local no effect method:
Before, using a local no effect method::
class Select:
@ -90,7 +96,7 @@ How To Use
3 : self.c
}.get(input, self.nop)(input)
After:
After::
class Select:
@ -111,20 +117,26 @@ How To Use
References
==========
[1] Python Reference Manual, Section 3.2,
.. [1] Python Reference Manual, Section 3.2,
http://docs.python.org/reference/
.. [2] Raymond Hettinger, Propose to reject PEP 336 -- Make None Callable
https://mail.python.org/pipermail/python-dev/2005-June/054280.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
sentence-end-double-space: t
fill-column: 70
End:
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:

114
pep-3142.txt
View File

@ -5,7 +5,7 @@ Last-Modified: $Date$
Author: Gerald Britton <gerald.britton@gmail.com>
Status: Rejected
Type: Standards Track
Content-Type: text/plain
Content-Type: text/x-rst
Created: 12-Jan-2009
Python-Version: 3.0
Post-History:
@ -13,25 +13,27 @@ Resolution: http://mail.python.org/pipermail/python-dev/2013-May/126136.html
Abstract
========
This PEP proposes an enhancement to generator expressions, adding a
"while" clause to complement the existing "if" clause.
This PEP proposes an enhancement to generator expressions, adding a
"while" clause to complement the existing "if" clause.
Rationale
=========
A generator expression (PEP 289 [1]) is a concise method to serve
dynamically-generated objects to list comprehensions (PEP 202 [2]).
Current generator expressions allow for an "if" clause to filter
the objects that are returned to those meeting some set of
criteria. However, since the "if" clause is evaluated for every
object that may be returned, in some cases it is possible that all
objects would be rejected after a certain point. For example:
A generator expression (PEP 289 [1]_) is a concise method to serve
dynamically-generated objects to list comprehensions (PEP 202 [2]_).
Current generator expressions allow for an "if" clause to filter
the objects that are returned to those meeting some set of
criteria. However, since the "if" clause is evaluated for every
object that may be returned, in some cases it is possible that all
objects would be rejected after a certain point. For example::
g = (n for n in range(100) if n*n < 50)
which is equivalent to the using a generator function
(PEP 255 [3]):
which is equivalent to the using a generator function
(PEP 255 [3]_)::
def __gen(exp):
for n in exp:
@ -39,16 +41,16 @@ Rationale
yield n
g = __gen(iter(range(10)))
would yield 0, 1, 2, 3, 4, 5, 6 and 7, but would also consider
the numbers from 8 to 99 and reject them all since n*n >= 50 for
numbers in that range. Allowing for a "while" clause would allow
the redundant tests to be short-circuited:
would yield 0, 1, 2, 3, 4, 5, 6 and 7, but would also consider
the numbers from 8 to 99 and reject them all since ``n*n >= 50`` for
numbers in that range. Allowing for a "while" clause would allow
the redundant tests to be short-circuited::
g = (n for n in range(100) while n*n < 50)
would also yield 0, 1, 2, 3, 4, 5, 6 and 7, but would stop at 8
since the condition (n*n < 50) is no longer true. This would be
equivalent to the generator function:
would also yield 0, 1, 2, 3, 4, 5, 6 and 7, but would stop at 8
since the condition (``n*n < 50``) is no longer true. This would be
equivalent to the generator function::
def __gen(exp):
for n in exp:
@ -58,71 +60,75 @@ Rationale
break
g = __gen(iter(range(100)))
Currently, in order to achieve the same result, one would need to
either write a generator function such as the one above or use the
takewhile function from itertools:
Currently, in order to achieve the same result, one would need to
either write a generator function such as the one above or use the
takewhile function from itertools::
from itertools import takewhile
g = takewhile(lambda n: n*n < 50, range(100))
The takewhile code achieves the same result as the proposed syntax,
albeit in a longer (some would say "less-elegant") fashion. Also,
the takewhile version requires an extra function call (the lambda
in the example above) with the associated performance penalty.
A simple test shows that:
The takewhile code achieves the same result as the proposed syntax,
albeit in a longer (some would say "less-elegant") fashion. Also,
the takewhile version requires an extra function call (the lambda
in the example above) with the associated performance penalty.
A simple test shows that::
for n in (n for n in range(100) if 1): pass
performs about 10% better than:
performs about 10% better than::
for n in takewhile(lambda n: 1, range(100)): pass
though they achieve similar results. (The first example uses a
generator; takewhile is an iterator). If similarly implemented,
a "while" clause should perform about the same as the "if" clause
does today.
though they achieve similar results. (The first example uses a
generator; takewhile is an iterator). If similarly implemented,
a "while" clause should perform about the same as the "if" clause
does today.
The reader may ask if the "if" and "while" clauses should be
mutually exclusive. There are good examples that show that there
are times when both may be used to good advantage. For example:
The reader may ask if the "if" and "while" clauses should be
mutually exclusive. There are good examples that show that there
are times when both may be used to good advantage. For example::
p = (p for p in primes() if p > 100 while p < 1000)
should return prime numbers found between 100 and 1000, assuming
I have a primes() generator that yields prime numbers.
should return prime numbers found between 100 and 1000, assuming
I have a ``primes()`` generator that yields prime numbers.
Adding a "while" clause to generator expressions maintains the
compact form while adding a useful facility for short-circuiting
the expression.
Adding a "while" clause to generator expressions maintains the
compact form while adding a useful facility for short-circuiting
the expression.
Acknowledgements
================
Raymond Hettinger first proposed the concept of generator
expressions in January 2002.
Raymond Hettinger first proposed the concept of generator
expressions in January 2002.
References
==========
[1] PEP 289: Generator Expressions
.. [1] PEP 289: Generator Expressions
http://www.python.org/dev/peps/pep-0289/
[2] PEP 202: List Comprehensions
.. [2] PEP 202: List Comprehensions
http://www.python.org/dev/peps/pep-0202/
[3] PEP 255: Simple Generators
.. [3] PEP 255: Simple Generators
http://www.python.org/dev/peps/pep-0255/
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: