diff --git a/pep-0215.txt b/pep-0215.txt index 6bc2779f6c1..3e577a63c5b 100644 --- a/pep-0215.txt +++ b/pep-0215.txt @@ -5,139 +5,154 @@ 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. +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 - 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.) +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.) - 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. - - >>> a, b = 5, 6 - >>> print $'a = $a, b = $b' - a = 5, b = 6 - >>> $u'uni${a}ode' - u'uni5ode' - >>> print $'\$a' - 5 - >>> print $r'\$a' - \5 - >>> print $'$$$a.$b' - $5.6 - >>> print $'a + b = ${a + b}' - a + b = 11 - >>> import sys - >>> print $'References to $a: $sys.getrefcount(a)' - References to 5: 15 - >>> print $"sys = $sys, sys = $sys.modules['sys']" - sys = , sys = - >>> print $'BDFL = $sys.copyright.split()[4].upper()' - BDFL = GUIDO +======== + +Here is an example of an interactive session exhibiting the +expected behaviour of this feature:: + + >>> a, b = 5, 6 + >>> print $'a = $a, b = $b' + a = 5, b = 6 + >>> $u'uni${a}ode' + u'uni5ode' + >>> print $'\$a' + 5 + >>> print $r'\$a' + \5 + >>> print $'$$$a.$b' + $5.6 + >>> print $'a + b = ${a + b}' + a + b = 11 + >>> import sys + >>> print $'References to $a: $sys.getrefcount(a)' + References to 5: 15 + >>> print $"sys = $sys, sys = $sys.modules['sys']" + sys = , sys = + >>> print $'BDFL = $sys.copyright.split()[4].upper()' + BDFL = GUIDO 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 [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:: + + $'a = $a, b = $b' - 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. +could be compiled as though it were the expression:: - As an optimization, interpolated strings could be compiled - directly into the corresponding bytecode; that is, + ('a = ' + str(a) + ', b = ' + str(b)) - $'a = $a, b = $b' +so that it only needs to be compiled once. - could be compiled as though it were the expression - ('a = ' + str(a) + ', b = ' + str(b)) +References +========== - so that it only needs to be compiled once. +.. [1] http://www.lfw.org/python/Itpl.py - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + End: diff --git a/pep-0226.txt b/pep-0226.txt index b1477a7e1a4..a1a030c0259 100644 --- a/pep-0226.txt +++ b/pep-0226.txt @@ -5,121 +5,132 @@ Last-Modified: $Date$ Author: Jeremy Hylton 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. +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 + 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. - - 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 + sense for you to fix it. - - 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 + sense to ask him or her first. - - 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 + and assign it to someone for review. - - 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: diff --git a/pep-0239.txt b/pep-0239.txt index 61d01e15f39..3c705e0511b 100644 --- a/pep-0239.txt +++ b/pep-0239.txt @@ -2,133 +2,147 @@ PEP: 239 Title: Adding a Rational Type to Python Version: $Revision$ Last-Modified: $Date$ -Author: Christopher A. Craig , - Moshe Zadka +Author: Christopher A. Craig , Moshe Zadka 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 [2]_. - 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. +*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 + 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 + rational(n, d) * d == n Open Issues +=========== - - 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. +- 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? - For rational numbers with integer values? +- 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: + Arguments for unifying ints with rationals: - - Since 2 == 2/1 and maybe str(2/1) == '2', it reduces surprises - where objects seem equal but behave differently. + - 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 - there is no remainder (if I am wrong and there is a remainder, - there will probably be some exception later). + - / can be freely used for integer division when I *know* that + there is no remainder (if I am wrong and there is a remainder, + there will probably be some exception later). - Arguments against: + Arguments against: - - When I use the result of / as a sequence index, it's usually - an error which should not be hidden by making the program - working for some data, since it will break for other data. + - When I use the result of / as a sequence index, it's usually + an error which should not be hidden by making the program + working for some data, since it will break for other data. - - (this assumes that after unification int and rational would be - different types:) Types should rarely depend on values. It's - easier to reason when the type of a variable is known: I know - how I can use it. I can determine that something is an int and - expect that other objects used in this place will be ints too. + - (this assumes that after unification int and rational would be + different types:) Types should rarely depend on values. It's + easier to reason when the type of a variable is known: I know + how I can use it. I can determine that something is an int and + expect that other objects used in this place will be ints too. - - (this assumes the same type for them:) Int is a good type in - itself, not to be mixed with rationals. The fact that - something is an integer should be expressible as a statement - about its type. Many operations require ints and don't accept - rationals. It's natural to think about them as about different - types. + - (this assumes the same type for them:) Int is a good type in + itself, not to be mixed with rationals. The fact that + something is an integer should be expressible as a statement + about its type. Many operations require ints and don't accept + rationals. It's natural to think about them as about different + types. References +========== - [1] PEP 240, Adding a Rational Literal to Python, Zadka, - http://www.python.org/dev/peps/pep-0240/ +.. [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: diff --git a/pep-0250.txt b/pep-0250.txt index 579fe4a734b..618acb4fe84 100644 --- a/pep-0250.txt +++ b/pep-0250.txt @@ -5,134 +5,142 @@ 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. - - 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. - - 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. +========== + +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. + +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. 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, - "lib", - "python" + sys.version[:3], - "site-packages"), - makepath(prefix, "lib", "site-python")] - elif os.sep == ':': - sitedirs = [makepath(prefix, "lib", "site-packages")] - else: - sitedirs = [prefix] + if os.sep == '/': + sitedirs = [makepath(prefix, + "lib", + "python" + sys.version[:3], + "site-packages"), + makepath(prefix, "lib", "site-python")] + elif os.sep == ':': + sitedirs = [makepath(prefix, "lib", "site-packages")] + 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")] + 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 - does not remove anything. +- 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 - will be recognised in either location. +- 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 - 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 - common location available on Windows, there is also no need for - having two separate package directories. +- 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 + 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 - 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 - necessary. +- 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 + necessary. Open Issues +=========== - - 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. +- 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 in other PEPs. - - 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. +- 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: diff --git a/pep-0259.txt b/pep-0259.txt index fb9c5635acd..a7c0e6c12bc 100644 --- a/pep-0259.txt +++ b/pep-0259.txt @@ -5,129 +5,140 @@ 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 - ... - root:x:0:0:root:/root:/bin/bash + >>> for line in open("/etc/passwd").readlines(): + ... print line + ... + root:x:0:0:root:/root:/bin/bash - bin:x:1:1:bin:/bin: + bin:x:1:1:bin:/bin: - daemon:x:2:2:daemon:/sbin: + daemon:x:2:2:daemon:/sbin: - (etc.) + (etc.) - >>> + >>> - 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 - newline +- ``-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 - whitespace character that's neither space nor newline +- ``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 - object written is an empty string or not a string) +- ``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 + 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 + 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 + 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' - please). +- 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: diff --git a/pep-0264.txt b/pep-0264.txt index d28577f19f4..2f960a5e654 100644 --- a/pep-0264.txt +++ b/pep-0264.txt @@ -5,6 +5,7 @@ Last-Modified: $Date$ Author: Michael Hudson 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, "", "suite", - __future__.generators.compiler_flag) + import __future__ + def compile_generator(func_def): + return compile(func_def, "", "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: diff --git a/pep-0274.txt b/pep-0274.txt index c98995763dd..1177ad83535 100644 --- a/pep-0274.txt +++ b/pep-0274.txt @@ -5,131 +5,138 @@ Last-Modified: $Date$ Author: Barry Warsaw 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, - (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} +>>> 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} -Implementation +>>> 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} - All implementation details were resolved in the Python 2.7 and 3.0 - time-frame. +>>> {(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} -References +Implementation +============== - [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: diff --git a/pep-0313.txt b/pep-0313.txt index bc7114021f9..20b9ea46870 100644 --- a/pep-0313.txt +++ b/pep-0313.txt @@ -5,124 +5,134 @@ Last-Modified: $Date$ Author: Mike Meyer 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 - http://www.python.org/dev/peps/pep-0239/ +.. [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 - http://www.python.org/dev/peps/pep-0240/ +.. [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 - http://www.python.org/dev/peps/pep-0008/ +.. [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: diff --git a/pep-0336.txt b/pep-0336.txt index 03047c51a33..072f9874756 100644 --- a/pep-0336.txt +++ b/pep-0336.txt @@ -1,130 +1,142 @@ PEP: 336 Title: Make None Callable Version: $Revision$ -Last-Modified: $Date$ +Last-Modified: $Date$ Author: Andrew McClelland Status: Rejected Type: Standards Track -Content-Type: text/plain +Content-Type: text/x-rst Created: 28-Oct-2004 -Post-History: +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: + class None: - def __call__(self, *args): - pass + def __call__(self, *args): + pass How To Use +========== - Before, checking function table entry against None: +Before, checking function table entry against ``None``:: - class Select: + class Select: - def a(self, input): - print 'a' + def a(self, input): + print 'a' - def b(self, input): - print 'b' + def b(self, input): + print 'b' - def c(self, input); - print 'c' + def c(self, input); + print 'c' - def __call__(self, input): - function = { 1 : self.a, - 2 : self.b, - 3 : self.c - }.get(input, None) - if function: return function(input) + def __call__(self, input): + function = { 1 : self.a, + 2 : self.b, + 3 : self.c + }.get(input, None) + if function: return function(input) - Before, using a local no effect method: +Before, using a local no effect method:: - class Select: + class Select: - def a(self, input): - print 'a' + def a(self, input): + print 'a' - def b(self, input): - print 'b' + def b(self, input): + print 'b' - def c(self, input); - print 'c' + def c(self, input); + print 'c' - def nop(self, input): - pass + def nop(self, input): + pass - def __call__(self, input): - return { 1 : self.a, - 2 : self.b, - 3 : self.c - }.get(input, self.nop)(input) + def __call__(self, input): + return { 1 : self.a, + 2 : self.b, + 3 : self.c + }.get(input, self.nop)(input) - After: +After:: - class Select: + class Select: - def a(self, input): - print 'a' + def a(self, input): + print 'a' - def b(self, input): - print 'b' + def b(self, input): + print 'b' - def c(self, input); - print 'c' + def c(self, input); + print 'c' - def __call__(self, input): - return { 1 : self.a, - 2 : self.b, - 3 : self.c - }.get(input, None)(input) + def __call__(self, input): + return { 1 : self.a, + 2 : self.b, + 3 : self.c + }.get(input, None)(input) References +========== + +.. [1] Python Reference Manual, Section 3.2, + http://docs.python.org/reference/ - [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: diff --git a/pep-3142.txt b/pep-3142.txt index d85c55f30dc..67c9bb4795d 100644 --- a/pep-3142.txt +++ b/pep-3142.txt @@ -5,7 +5,7 @@ Last-Modified: $Date$ Author: Gerald Britton 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,116 +13,122 @@ 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) + 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: - if n*n < 50: - yield n - g = __gen(iter(range(10))) + def __gen(exp): + for n in exp: + if n*n < 50: + 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) + 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: - if n*n < 50: - yield n - else: - break - g = __gen(iter(range(100))) + def __gen(exp): + for n in exp: + if n*n < 50: + yield n + else: + 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)) + 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 + 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 + 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) + 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: