diff --git a/pep-0221.txt b/pep-0221.txt index 92389a209..c2608e582 100644 --- a/pep-0221.txt +++ b/pep-0221.txt @@ -5,113 +5,120 @@ Last-Modified: $Date$ Author: thomas@python.org (Thomas Wouters) Status: Final Type: Standards Track +Content-Type: text/x-rst Created: 15-Aug-2000 Python-Version: 2.0 Post-History: Introduction +============ - This PEP describes the `import as' proposal for Python 2.0. This - PEP tracks the status and ownership of this feature. It contains - a description of the feature and outlines changes necessary to - support the feature. The CVS revision history of this file - contains the definitive historical record. +This PEP describes the ``import as`` proposal for Python 2.0. This +PEP tracks the status and ownership of this feature. It contains +a description of the feature and outlines changes necessary to +support the feature. The CVS revision history of this file +contains the definitive historical record. Rationale +========= - This PEP proposes an extension of Python syntax regarding the - `import' and `from import' statements. These statements - load in a module, and either bind that module to a local name, or - binds objects from that module to a local name. However, it is - sometimes desirable to bind those objects to a different name, for - instance to avoid name clashes. This can currently be achieved - using the following idiom: +This PEP proposes an extension of Python syntax regarding the +``import`` and ``from import`` statements. These statements +load in a module, and either bind that module to a local name, or +binds objects from that module to a local name. However, it is +sometimes desirable to bind those objects to a different name, for +instance to avoid name clashes. This can currently be achieved +using the following idiom:: - import os - real_os = os - del os - - And similarly for the `from ... import' statement: - - from os import fdopen, exit, stat - os_fdopen = fdopen - os_stat = stat - del fdopen, stat - - The proposed syntax change would add an optional `as' clause to - both these statements, as follows: + import os + real_os = os + del os - import os as real_os - from os import fdopen as os_fdopen, exit, stat as os_stat - - The `as' name is not intended to be a keyword, and some trickery - has to be used to convince the CPython parser it isn't one. For - more advanced parsers/tokenizers, however, this should not be a - problem. +And similarly for the ``from ... import`` statement:: - A slightly special case exists for importing sub-modules. The - statement + from os import fdopen, exit, stat + os_fdopen = fdopen + os_stat = stat + del fdopen, stat - import os.path +The proposed syntax change would add an optional ``as`` clause to +both these statements, as follows:: - stores the module `os' locally as `os', so that the imported - submodule `path' is accessible as `os.path'. As a result, - - import os.path as p + import os as real_os + from os import fdopen as os_fdopen, exit, stat as os_stat - stores `os.path', not `os', in `p'. This makes it effectively the - same as - - from os import path as p +The ``as`` name is not intended to be a keyword, and some trickery +has to be used to convince the CPython parser it isn't one. For +more advanced parsers/tokenizers, however, this should not be a +problem. + +A slightly special case exists for importing sub-modules. The +statement:: + + import os.path + +stores the module ``os`` locally as ``os``, so that the imported +submodule ``path`` is accessible as ``os.path``. As a result:: + + import os.path as p + +stores ``os.path``, not ``os``, in ``p``. This makes it effectively the +same as:: + + from os import path as p Implementation details +====================== - This PEP has been accepted, and the suggested code change has been - checked in. The patch can still be found in the SourceForge patch - manager[1]. Currently, a NAME field is used in the grammar rather - than a bare string, to avoid the keyword issue. It introduces a - new bytecode, IMPORT_STAR, which performs the `from module import - *' behaviour, and changes the behaviour of the IMPORT_FROM - bytecode so that it loads the requested name (which is always a - single name) onto the stack, to be subsequently stored by a STORE - opcode. As a result, all names explicitly imported now follow the - `global' directives. +This PEP has been accepted, and the suggested code change has been +checked in. The patch can still be found in the SourceForge patch +manager [1]_. Currently, a ``NAME`` field is used in the grammar rather +than a bare string, to avoid the keyword issue. It introduces a +new bytecode, ``IMPORT_STAR``, which performs the ``from module import +*`` behaviour, and changes the behaviour of the ``IMPORT_FROM`` +bytecode so that it loads the requested name (which is always a +single name) onto the stack, to be subsequently stored by a ``STORE`` +opcode. As a result, all names explicitly imported now follow the +``global`` directives. - The special case of `from module import *' remains a special case, - in that it cannot accommodate an `as' clause, and that no STORE - opcodes are generated; the objects imported are loaded directly - into the local namespace. This also means that names imported in - this fashion are always local, and do not follow the `global' - directive. - - An additional change to this syntax has also been suggested, to - generalize the expression given after the `as' clause. Rather - than a single name, it could be allowed to be any expression that - yields a valid l-value; anything that can be assigned to. The - change to accommodate this is minimal, as the patch[2] proves, and - the resulting generalization allows a number of new constructs - that run completely parallel with other Python assignment - constructs. However, this idea has been rejected by Guido, as - `hypergeneralization'. +The special case of ``from module import *`` remains a special case, +in that it cannot accommodate an ``as`` clause, and that no ``STORE`` +opcodes are generated; the objects imported are loaded directly +into the local namespace. This also means that names imported in +this fashion are always local, and do not follow the ``global`` +directive. + +An additional change to this syntax has also been suggested, to +generalize the expression given after the ``as`` clause. Rather +than a single name, it could be allowed to be any expression that +yields a valid l-value; anything that can be assigned to. The +change to accommodate this is minimal, as the patch [2]_ proves, and +the resulting generalization allows a number of new constructs +that run completely parallel with other Python assignment +constructs. However, this idea has been rejected by Guido, as +"hypergeneralization". Copyright +========= - This document has been placed in the Public Domain. +This document has been placed in the Public Domain. References +========== - [1] http://sourceforge.net/patch/?func=detailpatch&patch_id=101135&group_id=5470 +.. [1] https://hg.python.org/cpython/rev/18385172fac0 - [2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470 +.. [2] http://sourceforge.net/patch/?func=detailpatch&patch_id=101234&group_id=5470 - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + End: diff --git a/pep-0229.txt b/pep-0229.txt index 88d1383dc..8d2eed399 100644 --- a/pep-0229.txt +++ b/pep-0229.txt @@ -5,116 +5,123 @@ Last-Modified: $Date$ Author: A.M. Kuchling Status: Final Type: Standards Track +Content-Type: text/x-rst Created: 16-Nov-2000 Post-History: Introduction +============ - The Modules/Setup mechanism has some flaws: +The Modules/Setup mechanism has some flaws: - * People have to remember to uncomment bits of Modules/Setup in - order to get all the possible modules. +* People have to remember to uncomment bits of Modules/Setup in + order to get all the possible modules. - * Moving Setup to a new version of Python is tedious; new modules - have been added, so you can't just copy the older version, but - have to reconcile the two versions. +* Moving Setup to a new version of Python is tedious; new modules + have been added, so you can't just copy the older version, but + have to reconcile the two versions. - * Users have to figure out where the needed libraries, such as - zlib, are installed. +* Users have to figure out where the needed libraries, such as + ``zlib``, are installed. Proposal +======== - Use the Distutils to build the modules that come with Python. +Use the Distutils to build the modules that come with Python. - The changes can be broken up into several pieces: +The changes can be broken up into several pieces: - 1. The Distutils needs some Python modules to be able to build - modules. Currently I believe the minimal list is posix, _sre, - and string. +1. The Distutils needs some Python modules to be able to build + modules. Currently I believe the minimal list is posix, _sre, + and string. - These modules will have to be built before the Distutils can be - used, so they'll simply be hardwired into Modules/Makefile and - be automatically built. + These modules will have to be built before the Distutils can be + used, so they'll simply be hardwired into Modules/Makefile and + be automatically built. - 2. A top-level setup.py script will be written that checks the - libraries installed on the system and compiles as many modules - as possible. +2. A top-level setup.py script will be written that checks the + libraries installed on the system and compiles as many modules + as possible. - 3. Modules/Setup will be kept and settings in it will override - setup.py's usual behavior, so you can disable a module known - to be buggy, or specify particular compilation or linker flags. - However, in the common case where setup.py works correctly, - everything in Setup will remain commented out. The other - Setup.* become unnecessary, since nothing will be generating - Setup automatically. +3. Modules/Setup will be kept and settings in it will override + setup.py's usual behavior, so you can disable a module known + to be buggy, or specify particular compilation or linker flags. + However, in the common case where setup.py works correctly, + everything in Setup will remain commented out. The other + Setup.* become unnecessary, since nothing will be generating + Setup automatically. - The patch was checked in for Python 2.1, and has been subsequently - modified. +The patch was checked in for Python 2.1, and has been subsequently +modified. Implementation +============== - Patch #102588 on SourceForge contains the proposed patch. - Currently the patch tries to be conservative and to change as few - files as possible, in order to simplify backing out the patch. - For example, no attempt is made to rip out the existing build - mechanisms. Such simplifications can wait for later in the beta - cycle, when we're certain the patch will be left in, or they can - wait for Python 2.2. - - The patch makes the following changes: +Patch #102588 on SourceForge contains the proposed patch. +Currently the patch tries to be conservative and to change as few +files as possible, in order to simplify backing out the patch. +For example, no attempt is made to rip out the existing build +mechanisms. Such simplifications can wait for later in the beta +cycle, when we're certain the patch will be left in, or they can +wait for Python 2.2. - * Makes some required changes to distutils/sysconfig (these will - be checked in separately) +The patch makes the following changes: - * In the top-level Makefile.in, the "sharedmods" target simply - runs "./python setup.py build", and "sharedinstall" runs - "./python setup.py install". The "clobber" target also deletes - the build/ subdirectory where Distutils puts its output. +* Makes some required changes to distutils/sysconfig (these will + be checked in separately) - * Modules/Setup.config.in only contains entries for the gc and thread - modules; the readline, curses, and db modules are removed because - it's now setup.py's job to handle them. +* In the top-level Makefile.in, the "sharedmods" target simply + runs "./python setup.py build", and "sharedinstall" runs + "./python setup.py install". The "clobber" target also deletes + the build/ subdirectory where Distutils puts its output. - * Modules/Setup.dist now contains entries for only 3 modules -- - _sre, posix, and strop. +* Modules/Setup.config.in only contains entries for the gc and thread + modules; the readline, curses, and db modules are removed because + it's now setup.py's job to handle them. - * The configure script builds setup.cfg from setup.cfg.in. This - is needed for two reasons: to make building in subdirectories - work, and to get the configured installation prefix. +* Modules/Setup.dist now contains entries for only 3 modules -- + _sre, posix, and strop. - * Adds setup.py to the top directory of the source tree. setup.py - is the largest piece of the puzzle, though not the most - complicated. setup.py contains a subclass of the BuildExt - class, and extends it with a detect_modules() method that does - the work of figuring out when modules can be compiled, and adding - them to the 'exts' list. +* The configure script builds setup.cfg from setup.cfg.in. This + is needed for two reasons: to make building in subdirectories + work, and to get the configured installation prefix. + +* Adds setup.py to the top directory of the source tree. setup.py + is the largest piece of the puzzle, though not the most + complicated. setup.py contains a subclass of the BuildExt + class, and extends it with a detect_modules() method that does + the work of figuring out when modules can be compiled, and adding + them to the 'exts' list. Unresolved Issues - - Do we need to make it possible to disable the 3 hard-wired modules - without manually hacking the Makefiles? [Answer: No.] +================= - The Distutils always compile modules as shared libraries. How do - we support compiling them statically into the resulting Python - binary? +Do we need to make it possible to disable the 3 hard-wired modules +without manually hacking the Makefiles? [Answer: No.] - [Answer: building a Python binary with the Distutils should be - feasible, though no one has implemented it yet. This should be - done someday, but isn't a pressing priority as messing around with - the top-level Makefile.pre.in is good enough.] +The Distutils always compile modules as shared libraries. How do +we support compiling them statically into the resulting Python +binary? + +[Answer: building a Python binary with the Distutils should be +feasible, though no one has implemented it yet. This should be +done someday, but isn't a pressing priority as messing around with +the top-level Makefile.pre.in is good enough.] 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-0240.txt b/pep-0240.txt index 5b8fdcd47..3faa6b5e4 100644 --- a/pep-0240.txt +++ b/pep-0240.txt @@ -2,94 +2,108 @@ PEP: 240 Title: Adding a Rational Literal 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 +======== + +A different PEP [1]_ suggests adding a builtin rational type to +Python. This PEP suggests changing the ddd.ddd float literal to a +rational in Python, and modifying non-integer division to return +it. - A different PEP[1] suggests adding a builtin rational type to - Python. This PEP suggests changing the ddd.ddd float literal to a - rational in Python, and modifying non-integer division to return - it. 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. Rationale +========= - Rational numbers are useful for exact and unsurprising arithmetic. - They give the correct results people have been taught in various - math classes. Making the "obvious" non-integer type one with more - predictable semantics will surprise new programmers less than - using floating point numbers. As quite a few posts on c.l.py and - on tutor@python.org have shown, people often get bit by strange - semantics of floating point numbers: for example, round(0.98, 2) - still gives 0.97999999999999998. +Rational numbers are useful for exact and unsurprising arithmetic. +They give the correct results people have been taught in various +math classes. Making the "obvious" non-integer type one with more +predictable semantics will surprise new programmers less than +using floating point numbers. As quite a few posts on c.l.py and +on tutor@python.org have shown, people often get bit by strange +semantics of floating point numbers: for example, round(0.98, 2) +still gives 0.97999999999999998. Proposal +======== - Literals conforming to the regular expression '\d*.\d*' will be - rational numbers. +Literals conforming to the regular expression '\d*.\d*' will be +rational numbers. Backwards Compatibility +======================= - The only backwards compatible issue is the type of literals - mentioned above. The following migration is suggested: +The only backwards compatible issue is the type of literals +mentioned above. The following migration is suggested: - 1. The next Python after approval will allow - "from __future__ import rational_literals" - to cause all such literals to be treated as rational numbers. +1. The next Python after approval will allow + ``from __future__ import rational_literals`` + to cause all such literals to be treated as rational numbers. - 2. Python 3.0 will have a warning, turned on by default, about - such literals in the absence of a __future__ statement. The - warning message will contain information about the __future__ - statement, and indicate that to get floating point literals, - they should be suffixed with "e0". +2. Python 3.0 will have a warning, turned on by default, about + such literals in the absence of a `` __future__`` statement. The + warning message will contain information about the ``__future__`` + statement, and indicate that to get floating point literals, + they should be suffixed with "e0". - 3. Python 3.1 will have the warning turned off by default. This - warning will stay in place for 24 months, at which time the - literals will be rationals and the warning will be removed. +3. Python 3.1 will have the warning turned off by default. This + warning will stay in place for 24 months, at which time the + literals will be rationals and the warning will be removed. Common Objections +================= - Rationals are slow and memory intensive! - (Relax, I'm not taking floats away, I'm just adding two more characters. - 1e0 will still be a float) +Rationals are slow and memory intensive! +(Relax, I'm not taking floats away, I'm just adding two more characters. +1e0 will still be a float) + +Rationals must present themselves as a decimal float or they will be +horrible for users expecting decimals (i.e. ``str(.5)`` should return '.5' and +not '1/2'). This means that many rationals must be truncated at some +point, which gives us a new loss of precision. - Rationals must present themselves as a decimal float or they will be - horrible for users expecting decimals (i.e. str(.5) should return '.5' and - not '1/2'). This means that many rationals must be truncated at some - point, which gives us a new loss of precision. - References +========== - [1] PEP 239, Adding a Rational Type to Python, Zadka, - http://www.python.org/dev/peps/pep-0239/ +.. [1] PEP 239, Adding a Rational Type to Python, Zadka, + http://www.python.org/dev/peps/pep-0239/ +.. [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-0277.txt b/pep-0277.txt index 047ba629e..6bea69995 100644 --- a/pep-0277.txt +++ b/pep-0277.txt @@ -5,114 +5,121 @@ Last-Modified: $Date$ Author: neilh@scintilla.org (Neil Hodgson) Status: Final Type: Standards Track +Content-Type: text/x-rst Created: 11-Jan-2002 Python-Version: 2.3 Post-History: Abstract +======== - This PEP discusses supporting access to all files possible on - Windows NT by passing Unicode file names directly to the system's - wide-character functions. +This PEP discusses supporting access to all files possible on +Windows NT by passing Unicode file names directly to the system's +wide-character functions. Rationale +========= - Python 2.2 on Win32 platforms converts Unicode file names passed - to open and to functions in the os module into the 'mbcs' encoding - before passing the result to the operating system. This is often - successful in the common case where the script is operating with - the locale set to the same value as when the file was created. - Most machines are set up as one locale and rarely if ever changed - from this locale. For some users, locale is changed more often - and on servers there are often files saved by users using - different locales. +Python 2.2 on Win32 platforms converts Unicode file names passed +to open and to functions in the os module into the 'mbcs' encoding +before passing the result to the operating system. This is often +successful in the common case where the script is operating with +the locale set to the same value as when the file was created. +Most machines are set up as one locale and rarely if ever changed +from this locale. For some users, locale is changed more often +and on servers there are often files saved by users using +different locales. - On Windows NT and descendent operating systems, including Windows - 2000 and Windows XP, wide-character APIs are available that - provide direct access to all file names, including those that are - not representable using the current locale. The purpose of this - proposal is to provide access to these wide-character APIs through - the standard Python file object and posix module and so provide - access to all files on Windows NT. +On Windows NT and descendent operating systems, including Windows +2000 and Windows XP, wide-character APIs are available that +provide direct access to all file names, including those that are +not representable using the current locale. The purpose of this +proposal is to provide access to these wide-character APIs through +the standard Python file object and posix module and so provide +access to all files on Windows NT. Specification +============= - On Windows platforms which provide wide-character file APIs, when - Unicode arguments are provided to file APIs, wide-character calls - are made instead of the standard C library and posix calls. +On Windows platforms which provide wide-character file APIs, when +Unicode arguments are provided to file APIs, wide-character calls +are made instead of the standard C library and posix calls. - The Python file object is extended to use a Unicode file name - argument directly rather than converting it. This affects the - file object constructor file(filename[, mode[, bufsize]]) and also - the open function which is an alias of this constructor. When a - Unicode filename argument is used here then the name attribute of - the file object will be Unicode. The representation of a file - object, repr(f) will display Unicode file names as an escaped - string in a similar manner to the representation of Unicode - strings. +The Python file object is extended to use a Unicode file name +argument directly rather than converting it. This affects the +file object constructor ``file(filename[, mode[, bufsize]])`` and also +the open function which is an alias of this constructor. When a +Unicode filename argument is used here then the name attribute of +the file object will be Unicode. The representation of a file +object, ``repr(f)`` will display Unicode file names as an escaped +string in a similar manner to the representation of Unicode +strings. - The posix module contains functions that take file or directory - names: chdir, listdir, mkdir, open, remove, rename, rmdir, stat, - and _getfullpathname. These will use Unicode arguments directly - rather than converting them. For the rename function, this - behaviour is triggered when either of the arguments is Unicode and - the other argument converted to Unicode using the default - encoding. +The posix module contains functions that take file or directory +names: ``chdir``, ``listdir``, ``mkdir``, ``open``, ``remove``, ``rename``, +``rmdir``, ``stat``, and ``_getfullpathname``. These will use Unicode +arguments directly rather than converting them. For the rename function, this +behaviour is triggered when either of the arguments is Unicode and +the other argument converted to Unicode using the default +encoding. - The listdir function currently returns a list of strings. Under - this proposal, it will return a list of Unicode strings when its - path argument is Unicode. +The ``listdir`` function currently returns a list of strings. Under +this proposal, it will return a list of Unicode strings when its +path argument is Unicode. Restrictions +============ - On the consumer Windows operating systems, Windows 95, Windows 98, - and Windows ME, there are no wide-character file APIs so behaviour - is unchanged under this proposal. It may be possible in the - future to extend this proposal to cover these operating systems as - the VFAT-32 file system used by them does support Unicode file - names but access is difficult and so implementing this would - require much work. The "Microsoft Layer for Unicode" could be a - starting point for implementing this. +On the consumer Windows operating systems, Windows 95, Windows 98, +and Windows ME, there are no wide-character file APIs so behaviour +is unchanged under this proposal. It may be possible in the +future to extend this proposal to cover these operating systems as +the VFAT-32 file system used by them does support Unicode file +names but access is difficult and so implementing this would +require much work. The "Microsoft Layer for Unicode" could be a +starting point for implementing this. - Python can be compiled with the size of Unicode characters set to - 4 bytes rather than 2 by defining PY_UNICODE_TYPE to be a 4 byte - type and Py_UNICODE_SIZE to be 4. As the Windows API does not - accept 4 byte characters, the features described in this proposal - will not work in this mode so the implementation falls back to the - current 'mbcs' encoding technique. This restriction could be lifted - in the future by performing extra conversions using - PyUnicode_AsWideChar but for now that would add too much - complexity for a very rarely used feature. +Python can be compiled with the size of Unicode characters set to +4 bytes rather than 2 by defining ``PY_UNICODE_TYPE`` to be a 4 byte +type and ``Py_UNICODE_SIZE`` to be 4. As the Windows API does not +accept 4 byte characters, the features described in this proposal +will not work in this mode so the implementation falls back to the +current 'mbcs' encoding technique. This restriction could be lifted +in the future by performing extra conversions using +``PyUnicode_AsWideChar`` but for now that would add too much +complexity for a very rarely used feature. Reference Implementation +======================== - An experimental implementation is available from - [2] http://scintilla.sourceforge.net/winunichanges.zip - - [3] An updated version is available at - http://python.org/sf/594001 +The implementation is available at [2]_. References +========== - [1] Microsoft Windows APIs - http://msdn.microsoft.com/ +.. [1] Microsoft Windows APIs + http://msdn.microsoft.com/ + +.. [2] http://python.org/sf/594001 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-0286.txt b/pep-0286.txt index 1637eb9ee..85c3d8918 100644 --- a/pep-0286.txt +++ b/pep-0286.txt @@ -5,110 +5,130 @@ Last-Modified: $Date$ Author: martin@v.loewis.de (Martin von Löwis) Status: Deferred Type: Standards Track +Content-Type: text/x-rst Created: 3-Mar-2002 Python-Version: 2.3 -Post-History: +Post-History: Abstract +======== + +``PyArg_ParseTuple`` is confronted with difficult memory management if +an argument converter creates new memory. To deal with these +cases, a specialized argument type is proposed. - PyArg_ParseTuple is confronted with difficult memory management if - an argument converter creates new memory. To deal with these - cases, a specialized argument type is proposed. PEP Deferral +============ - Further exploration of the concepts covered in this PEP has been deferred - for lack of a current champion interested in promoting the goals of the - PEP and collecting and incorporating feedback, and with sufficient - available time to do so effectively. +Further exploration of the concepts covered in this PEP has been deferred +for lack of a current champion interested in promoting the goals of the +PEP and collecting and incorporating feedback, and with sufficient +available time to do so effectively. + +The resolution of this PEP may also be affected by the resolution of +PEP 426, which proposes the use of a preprocessing step to generate +some aspects of C API interface code. - The resolution of this PEP may also be affected by the resolution of - PEP 426, which proposes the use of a preprocessing step to generate - some aspects of C API interface code. Problem description +=================== - Today, argument tuples keep references to the function arguments, - which are guaranteed to live as long as the argument tuple exists - which is at least as long as the function call is being executed. +Today, argument tuples keep references to the function arguments, +which are guaranteed to live as long as the argument tuple exists +which is at least as long as the function call is being executed. - In some cases, parsing an argument will allocate new memory, which - is then to be released by the caller. This has two problems: +In some cases, parsing an argument will allocate new memory, which +is then to be released by the caller. This has two problems: - 1. In case of failure, the application cannot know what memory to - release; most callers don't even know that they have the - responsibility to release that memory. Example for this are - the N converter (bug #416288) and the es# converter (bug - #501716). +1. In case of failure, the application cannot know what memory to + release; most callers don't even know that they have the + responsibility to release that memory. Example for this are + the N converter (bug #416288 [1]_) and the es# converter (bug + #501716 [2]_). - 2. Even for successful argument parsing, it is still inconvenient - for the caller to be responsible for releasing the memory. In - some cases, this is unnecessarily inefficient. For example, - the es converter copies the conversion result into memory, even - though there already is a string object that has the right - contents. +2. Even for successful argument parsing, it is still inconvenient + for the caller to be responsible for releasing the memory. In + some cases, this is unnecessarily inefficient. For example, + the es converter copies the conversion result into memory, even + though there already is a string object that has the right + contents. Proposed solution +================= - A new type 'argument tuple' is introduced. This type derives from - tuple, adding an __dict__ member (at tp_dictoffset -4). Instances - of this type might get the following attributes: +A new type 'argument tuple' is introduced. This type derives from +tuple, adding an ``__dict__`` member (at ``tp_dictoffset`` -4). Instances +of this type might get the following attributes: - - 'failobjects', a list of objects which need to be deallocated - in case of success +- 'failobjects', a list of objects which need to be deallocated + in case of success - - 'okobjects', a list of object which will be released when the - argument tuple is released +- 'okobjects', a list of object which will be released when the + argument tuple is released - To manage this type, the following functions will be added, and - used appropriately in ceval.c and getargs.c: +To manage this type, the following functions will be added, and +used appropriately in ``ceval.c`` and ``getargs.c``: - - PyArgTuple_New(int); - - PyArgTuple_AddFailObject(PyObject*, PyObject*); - - PyArgTuple_AddFailMemory(PyObject*, void*); - - PyArgTuple_AddOkObject(PyObject*, PyObject*); - - PyArgTuple_AddOkMemory(PyObject*, void*); - - PyArgTuple_ClearFailed(PyObject*); +- ``PyArgTuple_New(int);`` +- ``PyArgTuple_AddFailObject(PyObject*, PyObject*);`` +- ``PyArgTuple_AddFailMemory(PyObject*, void*);`` +- ``PyArgTuple_AddOkObject(PyObject*, PyObject*);`` +- ``PyArgTuple_AddOkMemory(PyObject*, void*);`` +- ``PyArgTuple_ClearFailed(PyObject*);`` - When argument parsing fails, all fail objects will be released - through Py_DECREF, and all fail memory will be released through - PyMem_Free. If parsing succeeds, the references to the fail - objects and fail memory are dropped, without releasing anything. +When argument parsing fails, all fail objects will be released +through ``Py_DECREF``, and all fail memory will be released through +``PyMem_Free``. If parsing succeeds, the references to the fail +objects and fail memory are dropped, without releasing anything. - When the argument tuple is released, all ok objects and memory - will be released. +When the argument tuple is released, all ok objects and memory +will be released. - If those functions are called with an object of a different type, - a warning is issued and no further action is taken; usage of the - affected converters without using argument tuples is deprecated. +If those functions are called with an object of a different type, +a warning is issued and no further action is taken; usage of the +affected converters without using argument tuples is deprecated. Affected converters +=================== - The following converters will add fail memory and fail objects: N, - es, et, es#, et# (unless memory is passed into the converter) +The following converters will add fail memory and fail objects: N, +es, et, es#, et# (unless memory is passed into the converter) New converters +============== - To simplify Unicode conversion, the e* converters are duplicated - as E* converters (Es, Et, Es#, Et#). The usage of the E* - converters is identical to that of the e* converters, except that - the application will not need to manage the resulting memory. - This will be implemented through registration of Ok objects with - the argument tuple. The e* converters are deprecated. +To simplify Unicode conversion, the ``e*`` converters are duplicated +as ``E*`` converters (Es, Et, Es#, Et#). The usage of the ``E*`` +converters is identical to that of the ``e*`` converters, except that +the application will not need to manage the resulting memory. +This will be implemented through registration of Ok objects with +the argument tuple. The ``e*`` converters are deprecated. + + +References +========== + +.. [1] infrequent memory leak in pyexpat + (http://bugs.python.org/issue416288) + +.. [2] "es#" parser marker leaks memory + (http://bugs.python.org/issue501716) 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-0295.txt b/pep-0295.txt index 34cf7ab12..5396f2393 100644 --- a/pep-0295.txt +++ b/pep-0295.txt @@ -5,118 +5,127 @@ Last-Modified: $Date$ Author: yozh@mx1.ru (Stepan Koltsov) Status: Rejected Type: Standards Track +Content-Type: text/x-rst Created: 22-Jul-2002 Python-Version: 3.0 Post-History: -Abstract - This PEP describes an interpretation of multiline string constants - for Python. It suggests stripping spaces after newlines and - stripping a newline if it is first character after an opening - quotation. +Abstract +======== + +This PEP describes an interpretation of multiline string constants +for Python. It suggests stripping spaces after newlines and +stripping a newline if it is first character after an opening +quotation. Rationale +========= - This PEP proposes an interpretation of multiline string constants - in Python. Currently, the value of string constant is all the - text between quotations, maybe with escape sequences substituted, - e.g.: +This PEP proposes an interpretation of multiline string constants +in Python. Currently, the value of string constant is all the +text between quotations, maybe with escape sequences substituted, +e.g.:: - def f(): - """ - la-la-la - limona, banana - """ - - def g(): - return "This is \ - string" - - print repr(f.__doc__) - print repr(g()) - - prints: - - '\n\tla-la-la\n\tlimona, banana\n\t' - 'This is \tstring' - - This PEP suggest two things - - - ignore the first character after opening quotation, if it is - newline - - second: ignore in string constants all spaces and tabs up to - first non-whitespace character, but no more than current - indentation. - - After applying this, previous program will print: - - 'la-la-la\nlimona, banana\n' - 'This is string' - - To get this result, previous programs could be rewritten for - current Python as (note, this gives the same result with new - strings meaning): - - def f(): - """\ + def f(): + """ la-la-la limona, banana """ - - def g(): - "This is \ + + def g(): + return "This is \ string" - - Or stripping can be done with library routines at runtime (as - pydoc does), but this decreases program readability. + + print repr(f.__doc__) + print repr(g()) + +prints:: + + '\n\tla-la-la\n\tlimona, banana\n\t' + 'This is \tstring' + +This PEP suggest two things: + +- ignore the first character after opening quotation, if it is + newline + +- ignore in string constants all spaces and tabs up to + first non-whitespace character, but no more than current + indentation. + +After applying this, previous program will print:: + + 'la-la-la\nlimona, banana\n' + 'This is string' + +To get this result, previous programs could be rewritten for +current Python as (note, this gives the same result with new +strings meaning):: + + def f(): + """\ + la-la-la + limona, banana + """ + + def g(): + "This is \ + string" + +Or stripping can be done with library routines at runtime (as +pydoc does), but this decreases program readability. Implementation +============== - I'll say nothing about CPython, Jython or Python.NET. - - In original Python, there is no info about the current indentation - (in spaces) at compile time, so space and tab stripping should be - done at parse time. Currently no flags can be passed to the - parser in program text (like from __future__ import xxx). I - suggest enabling or disabling of this feature at Python compile - time depending of CPP flag Py_PARSE_MULTILINE_STRINGS. +I'll say nothing about CPython, Jython or Python.NET. + +In original Python, there is no info about the current indentation +(in spaces) at compile time, so space and tab stripping should be +done at parse time. Currently no flags can be passed to the +parser in program text (like ``from __future__ import xxx``). I +suggest enabling or disabling of this feature at Python compile +time depending of CPP flag ``Py_PARSE_MULTILINE_STRINGS``. Alternatives +============ - New interpretation of string constants can be implemented with flags - 'i' and 'o' to string constants, like - - i""" - SELECT * FROM car - WHERE model = 'i525' - """ is in new style, - - o"""SELECT * FROM employee - WHERE birth < 1982 - """ is in old style, and - - """ - SELECT employee.name, car.name, car.price FROM employee, car - WHERE employee.salary * 36 > car.price - """ is in new style after Python-x.y.z and in old style otherwise. - - Also this feature can be disabled if string is raw, i.e. if flag 'r' - specified. +New interpretation of string constants can be implemented with flags +'i' and 'o' to string constants, like:: + + i""" + SELECT * FROM car + WHERE model = 'i525' + """ is in new style, + + o"""SELECT * FROM employee + WHERE birth < 1982 + """ is in old style, and + + """ + SELECT employee.name, car.name, car.price FROM employee, car + WHERE employee.salary * 36 > car.price + """ is in new style after Python-x.y.z and in old style otherwise. + +Also this feature can be disabled if string is raw, i.e. if flag 'r' +specified. 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-0297.txt b/pep-0297.txt index 46e8ef844..76a36b71d 100644 --- a/pep-0297.txt +++ b/pep-0297.txt @@ -5,112 +5,125 @@ Last-Modified: $Date$ Author: mal@lemburg.com (Marc-André Lemburg) Status: Rejected Type: Standards Track +Content-Type: text/x-rst Created: 19-Jul-2001 Python-Version: 2.6 -Post-History: +Post-History: + Rejection Notice +================ - This PEP is rejected for failure to generate significant interest. +This PEP is rejected for failure to generate significant interest. Abstract +======== - This PEP proposes strategies to allow the Python standard library - to be upgraded in parts without having to reinstall the complete - distribution or having to wait for a new patch level release. +This PEP proposes strategies to allow the Python standard library +to be upgraded in parts without having to reinstall the complete +distribution or having to wait for a new patch level release. Problem +======= - Python currently does not allow overriding modules or packages in - the standard library per default. Even though this is possible by - defining a PYTHONPATH environment variable (the paths defined in - this variable are prepended to the Python standard library path), - there is no standard way of achieving this without changing the - configuration. +Python currently does not allow overriding modules or packages in +the standard library per default. Even though this is possible by +defining a ``PYTHONPATH`` environment variable (the paths defined in +this variable are prepended to the Python standard library path), +there is no standard way of achieving this without changing the +configuration. - Since Python's standard library is starting to host packages which - are also available separately, e.g. the distutils, email and PyXML - packages, which can also be installed independently of the Python - distribution, it is desirable to have an option to upgrade these - packages without having to wait for a new patch level release of - the Python interpreter to bring along the changes. +Since Python's standard library is starting to host packages which +are also available separately, e.g. the distutils, email and PyXML +packages, which can also be installed independently of the Python +distribution, it is desirable to have an option to upgrade these +packages without having to wait for a new patch level release of +the Python interpreter to bring along the changes. + +On some occasions, it may also be desirable to update modules of +the standard library without going through the whole Python release +cycle, e.g. in order to provide hot-fixes for security problems. - On some occasions, it may also be desirable to update modules of - the standard library without going through the whole Python release - cycle, e.g. in order to provide hot-fixes for security problems. Proposed Solutions +================== - This PEP proposes two different but not necessarily conflicting - solutions: +This PEP proposes two different but not necessarily conflicting +solutions: - 1. Adding a new standard search path to sys.path: - $stdlibpath/system-packages just before the $stdlibpath - entry. This complements the already existing entry for site - add-ons $stdlibpath/site-packages which is appended to the - sys.path at interpreter startup time. +1. Adding a new standard search path to ``sys.path``: + ``$stdlibpath/system-packages`` just before the ``$stdlibpath`` + entry. This complements the already existing entry for site + add-ons ``$stdlibpath/site-packages`` which is appended to the + ``sys.path`` at interpreter startup time. - To make use of this new standard location, distutils will need - to grow support for installing certain packages in - $stdlibpath/system-packages rather than the standard location - for third-party packages $stdlibpath/site-packages. + To make use of this new standard location, distutils will need + to grow support for installing certain packages in + ``$stdlibpath/system-packages`` rather than the standard location + for third-party packages ``$stdlibpath/site-packages``. - 2. Tweaking distutils to install directly into $stdlibpath for the - system upgrades rather than into $stdlibpath/site-packages. +2. Tweaking distutils to install directly into ``$stdlibpath`` for the + system upgrades rather than into ``$stdlibpath/site-packages``. - The first solution has a few advantages over the second: +The first solution has a few advantages over the second: - * upgrades can be easily identified (just look in - $stdlibpath/system-packages) +* upgrades can be easily identified (just look in + ``$stdlibpath/system-packages``) - * upgrades can be de-installed without affecting the rest - of the interpreter installation +* upgrades can be de-installed without affecting the rest + of the interpreter installation - * modules can be virtually removed from packages; this is - due to the way Python imports packages: once it finds the - top-level package directory it stay in this directory for - all subsequent package submodule imports +* modules can be virtually removed from packages; this is + due to the way Python imports packages: once it finds the + top-level package directory it stay in this directory for + all subsequent package submodule imports - * the approach has an overall much cleaner design than the - hackish install on top of an existing installation approach +* the approach has an overall much cleaner design than the + hackish install on top of an existing installation approach - The only advantages of the second approach are that the Python - interpreter does not have to changed and that it works with - older Python versions. +The only advantages of the second approach are that the Python +interpreter does not have to changed and that it works with +older Python versions. - Both solutions require changes to distutils. These changes can - also be implemented by package authors, but it would be better to - define a standard way of switching on the proposed behaviour. +Both solutions require changes to distutils. These changes can +also be implemented by package authors, but it would be better to +define a standard way of switching on the proposed behaviour. Scope +===== - Solution 1: Python 2.6 and up - Solution 2: all Python versions supported by distutils +Solution 1: Python 2.6 and up + +Solution 2: all Python versions supported by distutils Credits +======= - None +None References +========== - None +None 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: diff --git a/pep-0306.txt b/pep-0306.txt index c6c2cf7dd..594d73291 100644 --- a/pep-0306.txt +++ b/pep-0306.txt @@ -5,101 +5,111 @@ Last-Modified: $Date$ Author: Michael Hudson , Jack Diederich , Nick Coghlan , Benjamin Peterson Status: Withdrawn Type: Informational -Content-Type: text/plain +Content-Type: text/x-rst Created: 29-Jan-2003 Post-History: 30-Jan-2003 Note +==== - This PEP has been moved to the Python dev guide. +This PEP has been moved to the Python dev guide [1]_. Abstract +======== - There's more to changing Python's grammar than editing - Grammar/Grammar and Python/compile.c. This PEP aims to be a - checklist of places that must also be fixed. +There's more to changing Python's grammar than editing +Grammar/Grammar and Python/compile.c. This PEP aims to be a +checklist of places that must also be fixed. - It is probably incomplete. If you see omissions, just add them if - you can -- you are not going to offend the author's sense of - ownership. Otherwise submit a bug or patch and assign it to mwh. +It is probably incomplete. If you see omissions, just add them if +you can -- you are not going to offend the author's sense of +ownership. Otherwise submit a bug or patch and assign it to mwh. - This PEP is not intended to be an instruction manual on Python - grammar hacking, for several reasons. +This PEP is not intended to be an instruction manual on Python +grammar hacking, for several reasons. Rationale +========= - People are getting this wrong all the time; it took well over a - year before someone noticed[1] that adding the floor division - operator (//) broke the parser module. +People are getting this wrong all the time; it took well over a +year before someone noticed [2]_ that adding the floor division +operator (//) broke the parser module. Checklist +========= - __ Grammar/Grammar: OK, you'd probably worked this one out :) +- Grammar/Grammar: OK, you'd probably worked this one out :) - __ Parser/Python.asdl may need changes to match the Grammar. Run - make to regenerate Include/Python-ast.h and - Python/Python-ast.c. +- Parser/Python.asdl may need changes to match the Grammar. Run + make to regenerate Include/Python-ast.h and + Python/Python-ast.c. - __ Python/ast.c will need changes to create the AST objects - involved with the Grammar change. Lib/compiler/ast.py will - need matching changes to the pure-python AST objects. +- Python/ast.c will need changes to create the AST objects + involved with the Grammar change. Lib/compiler/ast.py will + need matching changes to the pure-python AST objects. - __ Parser/pgen needs to be rerun to regenerate Include/graminit.h - and Python/graminit.c. (make should handle this for you.) +- Parser/pgen needs to be rerun to regenerate Include/graminit.h + and Python/graminit.c. (make should handle this for you.) - __ Python/symbtable.c: This handles the symbol collection pass - that happens immediately before the compilation pass. +- Python/symbtable.c: This handles the symbol collection pass + that happens immediately before the compilation pass. - __ Python/compile.c: You will need to create or modify the - compiler_* functions to generate opcodes for your productions. +- Python/compile.c: You will need to create or modify the + ``compiler_*`` functions to generate opcodes for your productions. - __ You may need to regenerate Lib/symbol.py and/or Lib/token.py - and/or Lib/keyword.py. +- You may need to regenerate Lib/symbol.py and/or Lib/token.py + and/or Lib/keyword.py. - __ The parser module. Add some of your new syntax to test_parser, - bang on Modules/parsermodule.c until it passes. +- The parser module. Add some of your new syntax to test_parser, + bang on Modules/parsermodule.c until it passes. - __ Add some usage of your new syntax to test_grammar.py +- Add some usage of your new syntax to test_grammar.py - __ The compiler package. A good test is to compile the standard - library and test suite with the compiler package and then check - it runs. Note that this only needs to be done in Python 2.x. +- The compiler package. A good test is to compile the standard + library and test suite with the compiler package and then check + it runs. Note that this only needs to be done in Python 2.x. - __ If you've gone so far as to change the token structure of - Python, then the Lib/tokenizer.py library module will need to - be changed. +- If you've gone so far as to change the token structure of + Python, then the Lib/tokenizer.py library module will need to + be changed. - __ Certain changes may require tweaks to the library module - pyclbr. +- Certain changes may require tweaks to the library module + ``pyclbr``. - __ Documentation must be written! +- Documentation must be written! - __ After everything's been checked in, you're likely to see a new - change to Python/Python-ast.c. This is because this - (generated) file contains the SVN version of the source from - which it was generated. There's no way to avoid this; you just - have to submit this file separately. +- After everything's been checked in, you're likely to see a new + change to Python/Python-ast.c. This is because this + (generated) file contains the SVN version of the source from + which it was generated. There's no way to avoid this; you just + have to submit this file separately. References +========== - [1] SF Bug #676521, parser module validation failure - http://www.python.org/sf/676521 +.. [1] CPython Developer's Guide: Changing CPython's Grammar + http://cpython-devguide.readthedocs.io/en/latest/grammar.html + +.. [2] SF Bug #676521, parser module validation failure + http://www.python.org/sf/676521 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-0341.txt b/pep-0341.txt index 45092cb71..0c3bfd4cb 100644 --- a/pep-0341.txt +++ b/pep-0341.txt @@ -5,46 +5,61 @@ Last-Modified: $Date$ Author: Georg Brandl Status: Final Type: Standards Track -Content-Type: text/plain +Content-Type: text/x-rst Created: 04-May-2005 Post-History: Abstract +======== - This PEP proposes a change in the syntax and semantics of try - statements to allow combined try-except-finally blocks. This - means in short that it would be valid to write +This PEP proposes a change in the syntax and semantics of try +statements to allow combined try-except-finally blocks. This +means in short that it would be valid to write:: - try: - - except Exception: - - finally: - + try: + + except Exception: + + finally: + Rationale/Proposal +================== - There are many use cases for the try-except statement and - for the try-finally statement per se; however, often one needs - to catch exceptions and execute some cleanup code afterwards. - It is slightly annoying and not very intelligible that - one has to write +There are many use cases for the try-except statement and +for the try-finally statement per se; however, often one needs +to catch exceptions and execute some cleanup code afterwards. +It is slightly annoying and not very intelligible that +one has to write:: - f = None + f = None + try: try: - try: - f = open(filename) - text = f.read() - except IOError: - print 'An error occurred' - finally: - if f: - f.close() + f = open(filename) + text = f.read() + except IOError: + print 'An error occurred' + finally: + if f: + f.close() - So it is proposed that a construction like this +So it is proposed that a construction like this:: + try: + + except Ex1: + + + else: + + finally: + + +be exactly the same as the legacy:: + + try: try: except Ex1: @@ -52,72 +67,65 @@ Rationale/Proposal else: - finally: - + finally: + - be exactly the same as the legacy - - try: - try: - - except Ex1: - - - else: - - finally: - - - This is backwards compatible, and every try statement that is - legal today would continue to work. +This is backwards compatible, and every try statement that is +legal today would continue to work. Changes to the grammar +====================== - The grammar for the try statement, which is currently +The grammar for the try statement, which is currently:: - try_stmt: ('try' ':' suite (except_clause ':' suite)+ - ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) + try_stmt: ('try' ':' suite (except_clause ':' suite)+ + ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) - would have to become +would have to become:: + + try_stmt: 'try' ':' suite + ( + (except_clause ':' suite)+ + ['else' ':' suite] + ['finally' ':' suite] + | + 'finally' ':' suite + ) - try_stmt: 'try' ':' suite - ( - (except_clause ':' suite)+ - ['else' ':' suite] - ['finally' ':' suite] - | - 'finally' ':' suite - ) Implementation +============== - As the PEP author currently does not have sufficient knowledge - of the CPython implementation, he is unfortunately not able - to deliver one. Thomas Lee has submitted a patch[2]. +As the PEP author currently does not have sufficient knowledge +of the CPython implementation, he is unfortunately not able +to deliver one. Thomas Lee has submitted a patch [2]_. - However, according to Guido, it should be a piece of cake to - implement[1] -- at least for a core hacker. +However, according to Guido, it should be a piece of cake to +implement [1]_ -- at least for a core hacker. - This patch was committed 17 December 2005, SVN revision 41740 [3]. +This patch was committed 17 December 2005, SVN revision 41740 [3]_. References +========== - [1] http://mail.python.org/pipermail/python-dev/2005-May/053319.html - [2] http://python.org/sf/1355913 - [3] http://mail.python.org/pipermail/python-checkins/2005-December/048457.html +.. [1] http://mail.python.org/pipermail/python-dev/2005-May/053319.html +.. [2] http://python.org/sf/1355913 +.. [3] http://mail.python.org/pipermail/python-checkins/2005-December/048457.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-0666.txt b/pep-0666.txt index e533f53e7..e1c46909f 100644 --- a/pep-0666.txt +++ b/pep-0666.txt @@ -5,100 +5,106 @@ Last-Modified: $Date$ Author: lac@strakt.com (Laura Creighton) Status: Rejected Type: Standards Track +Content-Type: text/x-rst Created: 3-Dec-2001 Python-Version: 2.2 Post-History: 5-Dec-2001 Abstract +======== - Everybody agrees that mixing tabs and spaces is a bad idea. Some - people want more than this. I propose that we let people define - whatever Python behaviour they want, so it will only run the way - they like it, and will not run the way they don't like it. We - will do this with a command line switch. Programs that aren't - formatted the way the programmer wants things will raise - IndentationError: +Everybody agrees that mixing tabs and spaces is a bad idea. Some +people want more than this. I propose that we let people define +whatever Python behaviour they want, so it will only run the way +they like it, and will not run the way they don't like it. We +will do this with a command line switch. Programs that aren't +formatted the way the programmer wants things will raise +``IndentationError``. - Python -TNone will refuse to run when there are any tabs. - Python -Tn will refuse to run when tabs are not exactly n spaces - Python -TOnly will refuse to run when blocks are indented by anything - other than tabs +- ``Python -TNone`` will refuse to run when there are any tabs. +- ``Python -Tn`` will refuse to run when tabs are not exactly n spaces +- ``Python -TOnly`` will refuse to run when blocks are indented by anything + other than tabs - People who mix tabs and spaces, naturally, will find that their - programs do not run. Alas, we haven't found a way to give them an - electric shock as from a cattle prod remotely. (Though if somebody - finds out a way to do this, I will be pleased to add this option to - the PEP.) +People who mix tabs and spaces, naturally, will find that their +programs do not run. Alas, we haven't found a way to give them an +electric shock as from a cattle prod remotely. (Though if somebody +finds out a way to do this, I will be pleased to add this option to +the PEP.) - -Rationale - - Python-list@python.org (a.k.a. comp.lang.python) is periodically - awash with discussions about tabs and spaces. This is inevitable, - given that indentation is syntactically significant in Python. - This has never solved anything, and just makes various people - frustrated and angry. Eventually they start saying rude things to - each other which is sad for all of us. And it is also sad that - they are wasting their valuable time which they could spend - creating something with Python. Moreover, for the Python community - as a whole, from a public relations point of view, this is quite - unfortunate. The people who aren't posting about tabs and spaces, - are, (unsurprisingly) invisible, while the people who are posting - make the rest of us look somewhat foolish. - The problem is that there is no polite way to say 'Stop wasting - your valuable time and mine.' People who are already in the middle - of a flame war are not well disposed to believe that you are acting - out of compassion for them, and quite rightly insist that their own - time is their own to do with as they please. They are stuck like - flies in treacle in this wretched argument, and it is self-evident - that they cannot disengage or they would have already done so. +Rationale +========= - But today I had to spend time cleaning my keyboard because the 'n' - key is sticking. So, in addition to feeling compassion for these - people, I am pretty annoyed. I figure if I make this PEP, we can - then ask Guido to quickly reject it, and then when this argument - next starts up again, we can say 'Guido isn't changing things to - suit the tab-haters or the only-tabbers, so this conversation is a - waste of time.' Then everybody can quietly believe that a) they - are correct and b) other people are fools and c) they are - undeniably fortunate to not have to share a lab with idiots, (which - is something the arguers could do _now_, but apparently have - forgotten). +Python-list@python.org (a.k.a. comp.lang.python) is periodically +awash with discussions about tabs and spaces. This is inevitable, +given that indentation is syntactically significant in Python. +This has never solved anything, and just makes various people +frustrated and angry. Eventually they start saying rude things to +each other which is sad for all of us. And it is also sad that +they are wasting their valuable time which they could spend +creating something with Python. Moreover, for the Python community +as a whole, from a public relations point of view, this is quite +unfortunate. The people who aren't posting about tabs and spaces, +are, (unsurprisingly) invisible, while the people who are posting +make the rest of us look somewhat foolish. - And python-list can go back to worrying if it is too smug, rather - than whether it is too hostile for newcomers. Possibly somebody - could get around to explaining to me what is the difference between - __getattr__ and __getattribute__ in non-Classic classes in 2.2, a - question I have foolishly posted in the middle of the current tab - thread. I would like to know the answer to that question.[2] - - This proposal, if accepted, will probably mean a heck of a lot of - work for somebody. But since I don't want it accepted, I don't - care. +The problem is that there is no polite way to say 'Stop wasting +your valuable time and mine.' People who are already in the middle +of a flame war are not well disposed to believe that you are acting +out of compassion for them, and quite rightly insist that their own +time is their own to do with as they please. They are stuck like +flies in treacle in this wretched argument, and it is self-evident +that they cannot disengage or they would have already done so. + +But today I had to spend time cleaning my keyboard because the 'n' +key is sticking. So, in addition to feeling compassion for these +people, I am pretty annoyed. I figure if I make this PEP, we can +then ask Guido to quickly reject it, and then when this argument +next starts up again, we can say 'Guido isn't changing things to +suit the tab-haters or the only-tabbers, so this conversation is a +waste of time.' Then everybody can quietly believe that a) they +are correct and b) other people are fools and c) they are +undeniably fortunate to not have to share a lab with idiots, (which +is something the arguers could do _now_, but apparently have +forgotten). + +And python-list can go back to worrying if it is too smug, rather +than whether it is too hostile for newcomers. Possibly somebody +could get around to explaining to me what is the difference between +``__getattr__`` and ``__getattribute__`` in non-Classic classes in 2.2, a +question I have foolishly posted in the middle of the current tab +thread. I would like to know the answer to that question [2]_. + +This proposal, if accepted, will probably mean a heck of a lot of +work for somebody. But since I don't want it accepted, I don't +care. References +========== - [1] PEP 1, PEP Purpose and Guidelines - http://www.python.org/dev/peps/pep-0001/ +.. [1] PEP 1, PEP Purpose and Guidelines + http://www.python.org/dev/peps/pep-0001/ - [2] Tim Peters already has (private correspondence). My early 2.2 - didn't have a __getattribute__, and __getattr__ was - implemented like __getattribute__ now is. This has been - fixed. The important conclusion is that my Decorator Pattern - is safe and all is right with the world. +.. [2] Tim Peters already has (private correspondence). My early 2.2 + didn't have a ``__getattribute__``, and ``__getattr__`` was + implemented like ``__getattribute__`` now is. This has been + fixed. The important conclusion is that my Decorator Pattern + is safe and all is right with the world. 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: