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

reSTify 10 more PEPs (#175) 

PEP 221
PEP 229
PEP 240
PEP 277
PEP 286
PEP 295
PEP 297
PEP 306
PEP 341
PEP 666
This commit is contained in:
Mariatta 2017-01-09 22:52:57 -08:00 committed by Berker Peksag
parent a525758390
commit b54f01e13f
10 changed files with 788 additions and 687 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

161
pep-0221.txt
View File

@ -5,113 +5,120 @@ Last-Modified: $Date$
Author: thomas@python.org (Thomas Wouters) Author: thomas@python.org (Thomas Wouters)
Status: Final Status: Final
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 15-Aug-2000 Created: 15-Aug-2000
Python-Version: 2.0 Python-Version: 2.0
Post-History: Post-History:
Introduction Introduction
============
This PEP describes the `import as' proposal for Python 2.0. This This PEP describes the ``import as`` proposal for Python 2.0. This
PEP tracks the status and ownership of this feature. It contains PEP tracks the status and ownership of this feature. It contains
a description of the feature and outlines changes necessary to a description of the feature and outlines changes necessary to
support the feature. The CVS revision history of this file support the feature. The CVS revision history of this file
contains the definitive historical record. contains the definitive historical record.
Rationale Rationale
=========
This PEP proposes an extension of Python syntax regarding the This PEP proposes an extension of Python syntax regarding the
`import' and `from <module> import' statements. These statements ``import`` and ``from <module> import`` statements. These statements
load in a module, and either bind that module to a local name, or 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 binds objects from that module to a local name. However, it is
sometimes desirable to bind those objects to a different name, for sometimes desirable to bind those objects to a different name, for
instance to avoid name clashes. This can currently be achieved instance to avoid name clashes. This can currently be achieved
using the following idiom: using the following idiom::
import os import os
real_os = os real_os = os
del 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 as real_os And similarly for the ``from ... import`` statement::
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.
A slightly special case exists for importing sub-modules. The from os import fdopen, exit, stat
statement 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 import os as real_os
submodule `path' is accessible as `os.path'. As a result, from os import fdopen as os_fdopen, exit, stat as os_stat
import os.path as p
stores `os.path', not `os', in `p'. This makes it effectively the The ``as`` name is not intended to be a keyword, and some trickery
same as has to be used to convince the CPython parser it isn't one. For
more advanced parsers/tokenizers, however, this should not be a
from os import path as p 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 Implementation details
======================
This PEP has been accepted, and the suggested code change has been This PEP has been accepted, and the suggested code change has been
checked in. The patch can still be found in the SourceForge patch checked in. The patch can still be found in the SourceForge patch
manager[1]. Currently, a NAME field is used in the grammar rather manager [1]_. Currently, a ``NAME`` field is used in the grammar rather
than a bare string, to avoid the keyword issue. It introduces a than a bare string, to avoid the keyword issue. It introduces a
new bytecode, IMPORT_STAR, which performs the `from module import new bytecode, ``IMPORT_STAR``, which performs the ``from module import
*' behaviour, and changes the behaviour of the IMPORT_FROM *`` behaviour, and changes the behaviour of the ``IMPORT_FROM``
bytecode so that it loads the requested name (which is always a bytecode so that it loads the requested name (which is always a
single name) onto the stack, to be subsequently stored by a STORE single name) onto the stack, to be subsequently stored by a ``STORE``
opcode. As a result, all names explicitly imported now follow the opcode. As a result, all names explicitly imported now follow the
`global' directives. ``global`` directives.
The special case of `from module import *' remains a special case, The special case of ``from module import *`` remains a special case,
in that it cannot accommodate an `as' clause, and that no STORE in that it cannot accommodate an ``as`` clause, and that no ``STORE``
opcodes are generated; the objects imported are loaded directly opcodes are generated; the objects imported are loaded directly
into the local namespace. This also means that names imported in into the local namespace. This also means that names imported in
this fashion are always local, and do not follow the `global' this fashion are always local, and do not follow the ``global``
directive. directive.
An additional change to this syntax has also been suggested, to An additional change to this syntax has also been suggested, to
generalize the expression given after the `as' clause. Rather generalize the expression given after the ``as`` clause. Rather
than a single name, it could be allowed to be any expression that 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 yields a valid l-value; anything that can be assigned to. The
change to accommodate this is minimal, as the patch[2] proves, and change to accommodate this is minimal, as the patch [2]_ proves, and
the resulting generalization allows a number of new constructs the resulting generalization allows a number of new constructs
that run completely parallel with other Python assignment that run completely parallel with other Python assignment
constructs. However, this idea has been rejected by Guido, as constructs. However, this idea has been rejected by Guido, as
`hypergeneralization'. "hypergeneralization".
Copyright Copyright
=========
This document has been placed in the Public Domain. This document has been placed in the Public Domain.
References 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 Local Variables:
indent-tabs-mode: nil mode: indented-text
End: indent-tabs-mode: nil
End:

153
pep-0229.txt
View File

@ -5,116 +5,123 @@ Last-Modified: $Date$
Author: A.M. Kuchling <amk@amk.ca> Author: A.M. Kuchling <amk@amk.ca>
Status: Final Status: Final
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 16-Nov-2000 Created: 16-Nov-2000
Post-History: Post-History:
Introduction 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 * People have to remember to uncomment bits of Modules/Setup in
order to get all the possible modules. order to get all the possible modules.
* Moving Setup to a new version of Python is tedious; new 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 been added, so you can't just copy the older version, but
have to reconcile the two versions. have to reconcile the two versions.
* Users have to figure out where the needed libraries, such as * Users have to figure out where the needed libraries, such as
zlib, are installed. ``zlib``, are installed.
Proposal 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 1. The Distutils needs some Python modules to be able to build
modules. Currently I believe the minimal list is posix, _sre, modules. Currently I believe the minimal list is posix, _sre,
and string. and string.
These modules will have to be built before the Distutils can be These modules will have to be built before the Distutils can be
used, so they'll simply be hardwired into Modules/Makefile and used, so they'll simply be hardwired into Modules/Makefile and
be automatically built. be automatically built.
2. A top-level setup.py script will be written that checks the 2. A top-level setup.py script will be written that checks the
libraries installed on the system and compiles as many modules libraries installed on the system and compiles as many modules
as possible. as possible.
3. Modules/Setup will be kept and settings in it will override 3. Modules/Setup will be kept and settings in it will override
setup.py's usual behavior, so you can disable a module known setup.py's usual behavior, so you can disable a module known
to be buggy, or specify particular compilation or linker flags. to be buggy, or specify particular compilation or linker flags.
However, in the common case where setup.py works correctly, However, in the common case where setup.py works correctly,
everything in Setup will remain commented out. The other everything in Setup will remain commented out. The other
Setup.* become unnecessary, since nothing will be generating Setup.* become unnecessary, since nothing will be generating
Setup automatically. Setup automatically.
The patch was checked in for Python 2.1, and has been subsequently The patch was checked in for Python 2.1, and has been subsequently
modified. modified.
Implementation Implementation
==============
Patch #102588 on SourceForge contains the proposed patch. Patch #102588 on SourceForge contains the proposed patch.
Currently the patch tries to be conservative and to change as few Currently the patch tries to be conservative and to change as few
files as possible, in order to simplify backing out the patch. files as possible, in order to simplify backing out the patch.
For example, no attempt is made to rip out the existing build For example, no attempt is made to rip out the existing build
mechanisms. Such simplifications can wait for later in the beta mechanisms. Such simplifications can wait for later in the beta
cycle, when we're certain the patch will be left in, or they can cycle, when we're certain the patch will be left in, or they can
wait for Python 2.2. wait for Python 2.2.
The patch makes the following changes:
* Makes some required changes to distutils/sysconfig (these will The patch makes the following changes:
be checked in separately)
* In the top-level Makefile.in, the "sharedmods" target simply * Makes some required changes to distutils/sysconfig (these will
runs "./python setup.py build", and "sharedinstall" runs be checked in separately)
"./python setup.py install". The "clobber" target also deletes
the build/ subdirectory where Distutils puts its output.
* Modules/Setup.config.in only contains entries for the gc and thread * In the top-level Makefile.in, the "sharedmods" target simply
modules; the readline, curses, and db modules are removed because runs "./python setup.py build", and "sharedinstall" runs
it's now setup.py's job to handle them. "./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 -- * Modules/Setup.config.in only contains entries for the gc and thread
_sre, posix, and strop. 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 * Modules/Setup.dist now contains entries for only 3 modules --
is needed for two reasons: to make building in subdirectories _sre, posix, and strop.
work, and to get the configured installation prefix.
* Adds setup.py to the top directory of the source tree. setup.py * The configure script builds setup.cfg from setup.cfg.in. This
is the largest piece of the puzzle, though not the most is needed for two reasons: to make building in subdirectories
complicated. setup.py contains a subclass of the BuildExt work, and to get the configured installation prefix.
class, and extends it with a detect_modules() method that does
the work of figuring out when modules can be compiled, and adding * Adds setup.py to the top directory of the source tree. setup.py
them to the 'exts' list. 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 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 Do we need to make it possible to disable the 3 hard-wired modules
we support compiling them statically into the resulting Python without manually hacking the Makefiles? [Answer: No.]
binary?
[Answer: building a Python binary with the Distutils should be The Distutils always compile modules as shared libraries. How do
feasible, though no one has implemented it yet. This should be we support compiling them statically into the resulting Python
done someday, but isn't a pressing priority as messing around with binary?
the top-level Makefile.pre.in is good enough.]
[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 Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
End: indent-tabs-mode: nil
End:

114
pep-0240.txt
View File

@ -2,94 +2,108 @@ PEP: 240
Title: Adding a Rational Literal to Python Title: Adding a Rational Literal to Python
Version: $Revision$ Version: $Revision$
Last-Modified: $Date$ Last-Modified: $Date$
Author: Christopher A. Craig <python-pep@ccraig.org>, Author: Christopher A. Craig <python-pep@ccraig.org>, Moshe Zadka <moshez@zadka.site.co.il>
Moshe Zadka <moshez@zadka.site.co.il>
Status: Rejected Status: Rejected
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 11-Mar-2001 Created: 11-Mar-2001
Python-Version: 2.2 Python-Version: 2.2
Post-History: 16-Mar-2001 Post-History: 16-Mar-2001
Abstract 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 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 Rationale
=========
Rational numbers are useful for exact and unsurprising arithmetic. Rational numbers are useful for exact and unsurprising arithmetic.
They give the correct results people have been taught in various They give the correct results people have been taught in various
math classes. Making the "obvious" non-integer type one with more math classes. Making the "obvious" non-integer type one with more
predictable semantics will surprise new programmers less than predictable semantics will surprise new programmers less than
using floating point numbers. As quite a few posts on c.l.py and 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 on tutor@python.org have shown, people often get bit by strange
semantics of floating point numbers: for example, round(0.98, 2) semantics of floating point numbers: for example, round(0.98, 2)
still gives 0.97999999999999998. still gives 0.97999999999999998.
Proposal Proposal
========
Literals conforming to the regular expression '\d*.\d*' will be Literals conforming to the regular expression '\d*.\d*' will be
rational numbers. rational numbers.
Backwards Compatibility Backwards Compatibility
=======================
The only backwards compatible issue is the type of literals The only backwards compatible issue is the type of literals
mentioned above. The following migration is suggested: mentioned above. The following migration is suggested:
1. The next Python after approval will allow 1. The next Python after approval will allow
"from __future__ import rational_literals" ``from __future__ import rational_literals``
to cause all such literals to be treated as rational numbers. to cause all such literals to be treated as rational numbers.
2. Python 3.0 will have a warning, turned on by default, about 2. Python 3.0 will have a warning, turned on by default, about
such literals in the absence of a __future__ statement. The such literals in the absence of a `` __future__`` statement. The
warning message will contain information about the __future__ warning message will contain information about the ``__future__``
statement, and indicate that to get floating point literals, statement, and indicate that to get floating point literals,
they should be suffixed with "e0". they should be suffixed with "e0".
3. Python 3.1 will have the warning turned off by default. This 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 warning will stay in place for 24 months, at which time the
literals will be rationals and the warning will be removed. literals will be rationals and the warning will be removed.
Common Objections Common Objections
=================
Rationals are slow and memory intensive! Rationals are slow and memory intensive!
(Relax, I'm not taking floats away, I'm just adding two more characters. (Relax, I'm not taking floats away, I'm just adding two more characters.
1e0 will still be a float) 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 References
==========
[1] PEP 239, Adding a Rational Type to Python, Zadka, .. [1] PEP 239, Adding a Rational Type to Python, Zadka,
http://www.python.org/dev/peps/pep-0239/ 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 Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
End: indent-tabs-mode: nil
End:

151
pep-0277.txt
View File

@ -5,114 +5,121 @@ Last-Modified: $Date$
Author: neilh@scintilla.org (Neil Hodgson) Author: neilh@scintilla.org (Neil Hodgson)
Status: Final Status: Final
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 11-Jan-2002 Created: 11-Jan-2002
Python-Version: 2.3 Python-Version: 2.3
Post-History: Post-History:
Abstract Abstract
========
This PEP discusses supporting access to all files possible on This PEP discusses supporting access to all files possible on
Windows NT by passing Unicode file names directly to the system's Windows NT by passing Unicode file names directly to the system's
wide-character functions. wide-character functions.
Rationale Rationale
=========
Python 2.2 on Win32 platforms converts Unicode file names passed Python 2.2 on Win32 platforms converts Unicode file names passed
to open and to functions in the os module into the 'mbcs' encoding to open and to functions in the os module into the 'mbcs' encoding
before passing the result to the operating system. This is often before passing the result to the operating system. This is often
successful in the common case where the script is operating with successful in the common case where the script is operating with
the locale set to the same value as when the file was created. 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 Most machines are set up as one locale and rarely if ever changed
from this locale. For some users, locale is changed more often from this locale. For some users, locale is changed more often
and on servers there are often files saved by users using and on servers there are often files saved by users using
different locales. different locales.
On Windows NT and descendent operating systems, including Windows On Windows NT and descendent operating systems, including Windows
2000 and Windows XP, wide-character APIs are available that 2000 and Windows XP, wide-character APIs are available that
provide direct access to all file names, including those that are provide direct access to all file names, including those that are
not representable using the current locale. The purpose of this not representable using the current locale. The purpose of this
proposal is to provide access to these wide-character APIs through proposal is to provide access to these wide-character APIs through
the standard Python file object and posix module and so provide the standard Python file object and posix module and so provide
access to all files on Windows NT. access to all files on Windows NT.
Specification Specification
=============
On Windows platforms which provide wide-character file APIs, when On Windows platforms which provide wide-character file APIs, when
Unicode arguments are provided to file APIs, wide-character calls Unicode arguments are provided to file APIs, wide-character calls
are made instead of the standard C library and posix calls. are made instead of the standard C library and posix calls.
The Python file object is extended to use a Unicode file name The Python file object is extended to use a Unicode file name
argument directly rather than converting it. This affects the argument directly rather than converting it. This affects the
file object constructor file(filename[, mode[, bufsize]]) and also file object constructor ``file(filename[, mode[, bufsize]])`` and also
the open function which is an alias of this constructor. When a the open function which is an alias of this constructor. When a
Unicode filename argument is used here then the name attribute of Unicode filename argument is used here then the name attribute of
the file object will be Unicode. The representation of a file the file object will be Unicode. The representation of a file
object, repr(f) will display Unicode file names as an escaped object, ``repr(f)`` will display Unicode file names as an escaped
string in a similar manner to the representation of Unicode string in a similar manner to the representation of Unicode
strings. strings.
The posix module contains functions that take file or directory The posix module contains functions that take file or directory
names: chdir, listdir, mkdir, open, remove, rename, rmdir, stat, names: ``chdir``, ``listdir``, ``mkdir``, ``open``, ``remove``, ``rename``,
and _getfullpathname. These will use Unicode arguments directly ``rmdir``, ``stat``, and ``_getfullpathname``. These will use Unicode
rather than converting them. For the rename function, this arguments directly rather than converting them. For the rename function, this
behaviour is triggered when either of the arguments is Unicode and behaviour is triggered when either of the arguments is Unicode and
the other argument converted to Unicode using the default the other argument converted to Unicode using the default
encoding. encoding.
The listdir function currently returns a list of strings. Under The ``listdir`` function currently returns a list of strings. Under
this proposal, it will return a list of Unicode strings when its this proposal, it will return a list of Unicode strings when its
path argument is Unicode. path argument is Unicode.
Restrictions Restrictions
============
On the consumer Windows operating systems, Windows 95, Windows 98, On the consumer Windows operating systems, Windows 95, Windows 98,
and Windows ME, there are no wide-character file APIs so behaviour and Windows ME, there are no wide-character file APIs so behaviour
is unchanged under this proposal. It may be possible in the is unchanged under this proposal. It may be possible in the
future to extend this proposal to cover these operating systems as future to extend this proposal to cover these operating systems as
the VFAT-32 file system used by them does support Unicode file the VFAT-32 file system used by them does support Unicode file
names but access is difficult and so implementing this would names but access is difficult and so implementing this would
require much work. The "Microsoft Layer for Unicode" could be a require much work. The "Microsoft Layer for Unicode" could be a
starting point for implementing this. starting point for implementing this.
Python can be compiled with the size of Unicode characters set to 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 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 type and ``Py_UNICODE_SIZE`` to be 4. As the Windows API does not
accept 4 byte characters, the features described in this proposal accept 4 byte characters, the features described in this proposal
will not work in this mode so the implementation falls back to the will not work in this mode so the implementation falls back to the
current 'mbcs' encoding technique. This restriction could be lifted current 'mbcs' encoding technique. This restriction could be lifted
in the future by performing extra conversions using in the future by performing extra conversions using
PyUnicode_AsWideChar but for now that would add too much ``PyUnicode_AsWideChar`` but for now that would add too much
complexity for a very rarely used feature. complexity for a very rarely used feature.
Reference Implementation Reference Implementation
========================
An experimental implementation is available from The implementation is available at [2]_.
[2] http://scintilla.sourceforge.net/winunichanges.zip
[3] An updated version is available at
http://python.org/sf/594001
References References
==========
[1] Microsoft Windows APIs .. [1] Microsoft Windows APIs
http://msdn.microsoft.com/ http://msdn.microsoft.com/
.. [2] http://python.org/sf/594001
Copyright 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:

152
pep-0286.txt
View File

@ -5,110 +5,130 @@ Last-Modified: $Date$
Author: martin@v.loewis.de (Martin von Löwis) Author: martin@v.loewis.de (Martin von Löwis)
Status: Deferred Status: Deferred
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 3-Mar-2002 Created: 3-Mar-2002
Python-Version: 2.3 Python-Version: 2.3
Post-History: Post-History:
Abstract 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 PEP Deferral
============
Further exploration of the concepts covered in this PEP has been deferred 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 for lack of a current champion interested in promoting the goals of the
PEP and collecting and incorporating feedback, and with sufficient PEP and collecting and incorporating feedback, and with sufficient
available time to do so effectively. 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 Problem description
===================
Today, argument tuples keep references to the function arguments, Today, argument tuples keep references to the function arguments,
which are guaranteed to live as long as the argument tuple exists 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. which is at least as long as the function call is being executed.
In some cases, parsing an argument will allocate new memory, which In some cases, parsing an argument will allocate new memory, which
is then to be released by the caller. This has two problems: is then to be released by the caller. This has two problems:
1. In case of failure, the application cannot know what memory to 1. In case of failure, the application cannot know what memory to
release; most callers don't even know that they have the release; most callers don't even know that they have the
responsibility to release that memory. Example for this are responsibility to release that memory. Example for this are
the N converter (bug #416288) and the es# converter (bug the N converter (bug #416288 [1]_) and the es# converter (bug
#501716). #501716 [2]_).
2. Even for successful argument parsing, it is still inconvenient 2. Even for successful argument parsing, it is still inconvenient
for the caller to be responsible for releasing the memory. In for the caller to be responsible for releasing the memory. In
some cases, this is unnecessarily inefficient. For example, some cases, this is unnecessarily inefficient. For example,
the es converter copies the conversion result into memory, even the es converter copies the conversion result into memory, even
though there already is a string object that has the right though there already is a string object that has the right
contents. contents.
Proposed solution Proposed solution
=================
A new type 'argument tuple' is introduced. This type derives from A new type 'argument tuple' is introduced. This type derives from
tuple, adding an __dict__ member (at tp_dictoffset -4). Instances tuple, adding an ``__dict__`` member (at ``tp_dictoffset`` -4). Instances
of this type might get the following attributes: of this type might get the following attributes:
- 'failobjects', a list of objects which need to be deallocated - 'failobjects', a list of objects which need to be deallocated
in case of success in case of success
- 'okobjects', a list of object which will be released when the - 'okobjects', a list of object which will be released when the
argument tuple is released argument tuple is released
To manage this type, the following functions will be added, and To manage this type, the following functions will be added, and
used appropriately in ceval.c and getargs.c: used appropriately in ``ceval.c`` and ``getargs.c``:
- PyArgTuple_New(int); - ``PyArgTuple_New(int);``
- PyArgTuple_AddFailObject(PyObject*, PyObject*); - ``PyArgTuple_AddFailObject(PyObject*, PyObject*);``
- PyArgTuple_AddFailMemory(PyObject*, void*); - ``PyArgTuple_AddFailMemory(PyObject*, void*);``
- PyArgTuple_AddOkObject(PyObject*, PyObject*); - ``PyArgTuple_AddOkObject(PyObject*, PyObject*);``
- PyArgTuple_AddOkMemory(PyObject*, void*); - ``PyArgTuple_AddOkMemory(PyObject*, void*);``
- PyArgTuple_ClearFailed(PyObject*); - ``PyArgTuple_ClearFailed(PyObject*);``
When argument parsing fails, all fail objects will be released When argument parsing fails, all fail objects will be released
through Py_DECREF, and all fail memory will be released through through ``Py_DECREF``, and all fail memory will be released through
PyMem_Free. If parsing succeeds, the references to the fail ``PyMem_Free``. If parsing succeeds, the references to the fail
objects and fail memory are dropped, without releasing anything. objects and fail memory are dropped, without releasing anything.
When the argument tuple is released, all ok objects and memory When the argument tuple is released, all ok objects and memory
will be released. will be released.
If those functions are called with an object of a different type, 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 a warning is issued and no further action is taken; usage of the
affected converters without using argument tuples is deprecated. affected converters without using argument tuples is deprecated.
Affected converters Affected converters
===================
The following converters will add fail memory and fail objects: N, The following converters will add fail memory and fail objects: N,
es, et, es#, et# (unless memory is passed into the converter) es, et, es#, et# (unless memory is passed into the converter)
New converters New converters
==============
To simplify Unicode conversion, the e* converters are duplicated To simplify Unicode conversion, the ``e*`` converters are duplicated
as E* converters (Es, Et, Es#, Et#). The usage of the E* as ``E*`` converters (Es, Et, Es#, Et#). The usage of the ``E*``
converters is identical to that of the e* converters, except that converters is identical to that of the ``e*`` converters, except that
the application will not need to manage the resulting memory. the application will not need to manage the resulting memory.
This will be implemented through registration of Ok objects with This will be implemented through registration of Ok objects with
the argument tuple. The e* converters are deprecated. 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 Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
..
Local Variables: Local Variables:
mode: indented-text mode: indented-text
indent-tabs-mode: nil indent-tabs-mode: nil
fill-column: 70 fill-column: 70
End: End:

183
pep-0295.txt
View File

@ -5,118 +5,127 @@ Last-Modified: $Date$
Author: yozh@mx1.ru (Stepan Koltsov) Author: yozh@mx1.ru (Stepan Koltsov)
Status: Rejected Status: Rejected
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 22-Jul-2002 Created: 22-Jul-2002
Python-Version: 3.0 Python-Version: 3.0
Post-History: Post-History:
Abstract
This PEP describes an interpretation of multiline string constants Abstract
for Python. It suggests stripping spaces after newlines and ========
stripping a newline if it is first character after an opening
quotation. 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 Rationale
=========
This PEP proposes an interpretation of multiline string constants This PEP proposes an interpretation of multiline string constants
in Python. Currently, the value of string constant is all the in Python. Currently, the value of string constant is all the
text between quotations, maybe with escape sequences substituted, text between quotations, maybe with escape sequences substituted,
e.g.: e.g.::
def f(): 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():
"""\
la-la-la la-la-la
limona, banana limona, banana
""" """
def g(): def g():
"This is \ return "This is \
string" string"
Or stripping can be done with library routines at runtime (as print repr(f.__doc__)
pydoc does), but this decreases program readability. 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 Implementation
==============
I'll say nothing about CPython, Jython or Python.NET. I'll say nothing about CPython, Jython or Python.NET.
In original Python, there is no info about the current indentation In original Python, there is no info about the current indentation
(in spaces) at compile time, so space and tab stripping should be (in spaces) at compile time, so space and tab stripping should be
done at parse time. Currently no flags can be passed to the done at parse time. Currently no flags can be passed to the
parser in program text (like from __future__ import xxx). I parser in program text (like ``from __future__ import xxx``). I
suggest enabling or disabling of this feature at Python compile suggest enabling or disabling of this feature at Python compile
time depending of CPP flag Py_PARSE_MULTILINE_STRINGS. time depending of CPP flag ``Py_PARSE_MULTILINE_STRINGS``.
Alternatives Alternatives
============
New interpretation of string constants can be implemented with flags New interpretation of string constants can be implemented with flags
'i' and 'o' to string constants, like 'i' and 'o' to string constants, like::
i""" i"""
SELECT * FROM car SELECT * FROM car
WHERE model = 'i525' WHERE model = 'i525'
""" is in new style, """ is in new style,
o"""SELECT * FROM employee o"""SELECT * FROM employee
WHERE birth < 1982 WHERE birth < 1982
""" is in old style, and """ is in old style, and
""" """
SELECT employee.name, car.name, car.price FROM employee, car SELECT employee.name, car.name, car.price FROM employee, car
WHERE employee.salary * 36 > car.price WHERE employee.salary * 36 > car.price
""" is in new style after Python-x.y.z and in old style otherwise. """ 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' Also this feature can be disabled if string is raw, i.e. if flag 'r'
specified. specified.
Copyright Copyright
=========
This document has been placed in the Public Domain. This document has been placed in the Public Domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
sentence-end-double-space: t indent-tabs-mode: nil
fill-column: 70 sentence-end-double-space: t
End: fill-column: 70
End:

139
pep-0297.txt
View File

@ -5,112 +5,125 @@ Last-Modified: $Date$
Author: mal@lemburg.com (Marc-André Lemburg) Author: mal@lemburg.com (Marc-André Lemburg)
Status: Rejected Status: Rejected
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 19-Jul-2001 Created: 19-Jul-2001
Python-Version: 2.6 Python-Version: 2.6
Post-History: Post-History:
Rejection Notice Rejection Notice
================
This PEP is rejected for failure to generate significant interest. This PEP is rejected for failure to generate significant interest.
Abstract Abstract
========
This PEP proposes strategies to allow the Python standard library This PEP proposes strategies to allow the Python standard library
to be upgraded in parts without having to reinstall the complete to be upgraded in parts without having to reinstall the complete
distribution or having to wait for a new patch level release. distribution or having to wait for a new patch level release.
Problem Problem
=======
Python currently does not allow overriding modules or packages in Python currently does not allow overriding modules or packages in
the standard library per default. Even though this is possible by the standard library per default. Even though this is possible by
defining a PYTHONPATH environment variable (the paths defined in defining a ``PYTHONPATH`` environment variable (the paths defined in
this variable are prepended to the Python standard library path), this variable are prepended to the Python standard library path),
there is no standard way of achieving this without changing the there is no standard way of achieving this without changing the
configuration. configuration.
Since Python's standard library is starting to host packages which Since Python's standard library is starting to host packages which
are also available separately, e.g. the distutils, email and PyXML are also available separately, e.g. the distutils, email and PyXML
packages, which can also be installed independently of the Python packages, which can also be installed independently of the Python
distribution, it is desirable to have an option to upgrade these distribution, it is desirable to have an option to upgrade these
packages without having to wait for a new patch level release of packages without having to wait for a new patch level release of
the Python interpreter to bring along the changes. 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 Proposed Solutions
==================
This PEP proposes two different but not necessarily conflicting This PEP proposes two different but not necessarily conflicting
solutions: solutions:
1. Adding a new standard search path to sys.path: 1. Adding a new standard search path to ``sys.path``:
$stdlibpath/system-packages just before the $stdlibpath ``$stdlibpath/system-packages`` just before the ``$stdlibpath``
entry. This complements the already existing entry for site entry. This complements the already existing entry for site
add-ons $stdlibpath/site-packages which is appended to the add-ons ``$stdlibpath/site-packages`` which is appended to the
sys.path at interpreter startup time. ``sys.path`` at interpreter startup time.
To make use of this new standard location, distutils will need To make use of this new standard location, distutils will need
to grow support for installing certain packages in to grow support for installing certain packages in
$stdlibpath/system-packages rather than the standard location ``$stdlibpath/system-packages`` rather than the standard location
for third-party packages $stdlibpath/site-packages. for third-party packages ``$stdlibpath/site-packages``.
2. Tweaking distutils to install directly into $stdlibpath for the 2. Tweaking distutils to install directly into ``$stdlibpath`` for the
system upgrades rather than into $stdlibpath/site-packages. 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 * upgrades can be easily identified (just look in
$stdlibpath/system-packages) ``$stdlibpath/system-packages``)
* upgrades can be de-installed without affecting the rest * upgrades can be de-installed without affecting the rest
of the interpreter installation of the interpreter installation
* modules can be virtually removed from packages; this is * modules can be virtually removed from packages; this is
due to the way Python imports packages: once it finds the due to the way Python imports packages: once it finds the
top-level package directory it stay in this directory for top-level package directory it stay in this directory for
all subsequent package submodule imports all subsequent package submodule imports
* the approach has an overall much cleaner design than the * the approach has an overall much cleaner design than the
hackish install on top of an existing installation approach hackish install on top of an existing installation approach
The only advantages of the second approach are that the Python The only advantages of the second approach are that the Python
interpreter does not have to changed and that it works with interpreter does not have to changed and that it works with
older Python versions. older Python versions.
Both solutions require changes to distutils. These changes can Both solutions require changes to distutils. These changes can
also be implemented by package authors, but it would be better to also be implemented by package authors, but it would be better to
define a standard way of switching on the proposed behaviour. define a standard way of switching on the proposed behaviour.
Scope Scope
=====
Solution 1: Python 2.6 and up Solution 1: Python 2.6 and up
Solution 2: all Python versions supported by distutils
Solution 2: all Python versions supported by distutils
Credits Credits
=======
None None
References References
==========
None None
Copyright Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
sentence-end-double-space: t indent-tabs-mode: nil
fill-column: 70 sentence-end-double-space: t
coding: utf-8 fill-column: 70
End: coding: utf-8
End:

120
pep-0306.txt
View File

@ -5,101 +5,111 @@ Last-Modified: $Date$
Author: Michael Hudson <mwh@python.net>, Jack Diederich <jackdied@gmail.com>, Nick Coghlan <ncoghlan@gmail.com>, Benjamin Peterson <benjamin@python.org> Author: Michael Hudson <mwh@python.net>, Jack Diederich <jackdied@gmail.com>, Nick Coghlan <ncoghlan@gmail.com>, Benjamin Peterson <benjamin@python.org>
Status: Withdrawn Status: Withdrawn
Type: Informational Type: Informational
Content-Type: text/plain Content-Type: text/x-rst
Created: 29-Jan-2003 Created: 29-Jan-2003
Post-History: 30-Jan-2003 Post-History: 30-Jan-2003
Note Note
====
This PEP has been moved to the Python dev guide. This PEP has been moved to the Python dev guide [1]_.
Abstract Abstract
========
There's more to changing Python's grammar than editing There's more to changing Python's grammar than editing
Grammar/Grammar and Python/compile.c. This PEP aims to be a Grammar/Grammar and Python/compile.c. This PEP aims to be a
checklist of places that must also be fixed. checklist of places that must also be fixed.
It is probably incomplete. If you see omissions, just add them if 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 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. ownership. Otherwise submit a bug or patch and assign it to mwh.
This PEP is not intended to be an instruction manual on Python This PEP is not intended to be an instruction manual on Python
grammar hacking, for several reasons. grammar hacking, for several reasons.
Rationale Rationale
=========
People are getting this wrong all the time; it took well over a People are getting this wrong all the time; it took well over a
year before someone noticed[1] that adding the floor division year before someone noticed [2]_ that adding the floor division
operator (//) broke the parser module. operator (//) broke the parser module.
Checklist 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 - Parser/Python.asdl may need changes to match the Grammar. Run
make to regenerate Include/Python-ast.h and make to regenerate Include/Python-ast.h and
Python/Python-ast.c. Python/Python-ast.c.
__ Python/ast.c will need changes to create the AST objects - Python/ast.c will need changes to create the AST objects
involved with the Grammar change. Lib/compiler/ast.py will involved with the Grammar change. Lib/compiler/ast.py will
need matching changes to the pure-python AST objects. need matching changes to the pure-python AST objects.
__ Parser/pgen needs to be rerun to regenerate Include/graminit.h - Parser/pgen needs to be rerun to regenerate Include/graminit.h
and Python/graminit.c. (make should handle this for you.) and Python/graminit.c. (make should handle this for you.)
__ Python/symbtable.c: This handles the symbol collection pass - Python/symbtable.c: This handles the symbol collection pass
that happens immediately before the compilation pass. that happens immediately before the compilation pass.
__ Python/compile.c: You will need to create or modify the - Python/compile.c: You will need to create or modify the
compiler_* functions to generate opcodes for your productions. ``compiler_*`` functions to generate opcodes for your productions.
__ You may need to regenerate Lib/symbol.py and/or Lib/token.py - You may need to regenerate Lib/symbol.py and/or Lib/token.py
and/or Lib/keyword.py. and/or Lib/keyword.py.
__ The parser module. Add some of your new syntax to test_parser, - The parser module. Add some of your new syntax to test_parser,
bang on Modules/parsermodule.c until it passes. 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 - The compiler package. A good test is to compile the standard
library and test suite with the compiler package and then check 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. 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 - If you've gone so far as to change the token structure of
Python, then the Lib/tokenizer.py library module will need to Python, then the Lib/tokenizer.py library module will need to
be changed. be changed.
__ Certain changes may require tweaks to the library module - Certain changes may require tweaks to the library module
pyclbr. ``pyclbr``.
__ Documentation must be written! - Documentation must be written!
__ After everything's been checked in, you're likely to see a new - After everything's been checked in, you're likely to see a new
change to Python/Python-ast.c. This is because this change to Python/Python-ast.c. This is because this
(generated) file contains the SVN version of the source from (generated) file contains the SVN version of the source from
which it was generated. There's no way to avoid this; you just which it was generated. There's no way to avoid this; you just
have to submit this file separately. have to submit this file separately.
References References
==========
[1] SF Bug #676521, parser module validation failure .. [1] CPython Developer's Guide: Changing CPython's Grammar
http://www.python.org/sf/676521 http://cpython-devguide.readthedocs.io/en/latest/grammar.html
.. [2] SF Bug #676521, parser module validation failure
http://www.python.org/sf/676521
Copyright Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
sentence-end-double-space: t indent-tabs-mode: nil
fill-column: 70 sentence-end-double-space: t
End: fill-column: 70
End:

150
pep-0341.txt
View File

@ -5,46 +5,61 @@ Last-Modified: $Date$
Author: Georg Brandl <georg@python.org> Author: Georg Brandl <georg@python.org>
Status: Final Status: Final
Type: Standards Track Type: Standards Track
Content-Type: text/plain Content-Type: text/x-rst
Created: 04-May-2005 Created: 04-May-2005
Post-History: Post-History:
Abstract Abstract
========
This PEP proposes a change in the syntax and semantics of try This PEP proposes a change in the syntax and semantics of try
statements to allow combined try-except-finally blocks. This statements to allow combined try-except-finally blocks. This
means in short that it would be valid to write means in short that it would be valid to write::
try: try:
<do something> <do something>
except Exception: except Exception:
<handle the error> <handle the error>
finally: finally:
<cleanup> <cleanup>
Rationale/Proposal Rationale/Proposal
==================
There are many use cases for the try-except statement and There are many use cases for the try-except statement and
for the try-finally statement per se; however, often one needs for the try-finally statement per se; however, often one needs
to catch exceptions and execute some cleanup code afterwards. to catch exceptions and execute some cleanup code afterwards.
It is slightly annoying and not very intelligible that It is slightly annoying and not very intelligible that
one has to write one has to write::
f = None f = None
try:
try: try:
try: f = open(filename)
f = open(filename) text = f.read()
text = f.read() except IOError:
except IOError: print 'An error occurred'
print 'An error occurred' finally:
finally: if f:
if f: f.close()
f.close()
So it is proposed that a construction like this So it is proposed that a construction like this::
try:
<suite 1>
except Ex1:
<suite 2>
<more except: clauses>
else:
<suite 3>
finally:
<suite 4>
be exactly the same as the legacy::
try:
try: try:
<suite 1> <suite 1>
except Ex1: except Ex1:
@ -52,72 +67,65 @@ Rationale/Proposal
<more except: clauses> <more except: clauses>
else: else:
<suite 3> <suite 3>
finally: finally:
<suite 4> <suite 4>
be exactly the same as the legacy This is backwards compatible, and every try statement that is
legal today would continue to work.
try:
try:
<suite 1>
except Ex1:
<suite 2>
<more except: clauses>
else:
<suite 3>
finally:
<suite 4>
This is backwards compatible, and every try statement that is
legal today would continue to work.
Changes to the grammar 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)+ try_stmt: ('try' ':' suite (except_clause ':' suite)+
['else' ':' suite] | 'try' ':' suite 'finally' ':' 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 Implementation
==============
As the PEP author currently does not have sufficient knowledge As the PEP author currently does not have sufficient knowledge
of the CPython implementation, he is unfortunately not able of the CPython implementation, he is unfortunately not able
to deliver one. Thomas Lee has submitted a patch[2]. to deliver one. Thomas Lee has submitted a patch [2]_.
However, according to Guido, it should be a piece of cake to However, according to Guido, it should be a piece of cake to
implement[1] -- at least for a core hacker. 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 References
==========
[1] http://mail.python.org/pipermail/python-dev/2005-May/053319.html .. [1] http://mail.python.org/pipermail/python-dev/2005-May/053319.html
[2] http://python.org/sf/1355913 .. [2] http://python.org/sf/1355913
[3] http://mail.python.org/pipermail/python-checkins/2005-December/048457.html .. [3] http://mail.python.org/pipermail/python-checkins/2005-December/048457.html
Copyright Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
sentence-end-double-space: t indent-tabs-mode: nil
fill-column: 70 sentence-end-double-space: t
End: fill-column: 70
End:

152
pep-0666.txt
View File

@ -5,100 +5,106 @@ Last-Modified: $Date$
Author: lac@strakt.com (Laura Creighton) Author: lac@strakt.com (Laura Creighton)
Status: Rejected Status: Rejected
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst
Created: 3-Dec-2001 Created: 3-Dec-2001
Python-Version: 2.2 Python-Version: 2.2
Post-History: 5-Dec-2001 Post-History: 5-Dec-2001
Abstract Abstract
========
Everybody agrees that mixing tabs and spaces is a bad idea. Some Everybody agrees that mixing tabs and spaces is a bad idea. Some
people want more than this. I propose that we let people define people want more than this. I propose that we let people define
whatever Python behaviour they want, so it will only run the way 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 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 will do this with a command line switch. Programs that aren't
formatted the way the programmer wants things will raise formatted the way the programmer wants things will raise
IndentationError: ``IndentationError``.
Python -TNone will refuse to run when there are any 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 -Tn`` will refuse to run when tabs are not exactly n spaces
Python -TOnly will refuse to run when blocks are indented by anything - ``Python -TOnly`` will refuse to run when blocks are indented by anything
other than tabs other than tabs
People who mix tabs and spaces, naturally, will find that their 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 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 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 finds out a way to do this, I will be pleased to add this option to
the PEP.) 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 Rationale
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' Python-list@python.org (a.k.a. comp.lang.python) is periodically
key is sticking. So, in addition to feeling compassion for these awash with discussions about tabs and spaces. This is inevitable,
people, I am pretty annoyed. I figure if I make this PEP, we can given that indentation is syntactically significant in Python.
then ask Guido to quickly reject it, and then when this argument This has never solved anything, and just makes various people
next starts up again, we can say 'Guido isn't changing things to frustrated and angry. Eventually they start saying rude things to
suit the tab-haters or the only-tabbers, so this conversation is a each other which is sad for all of us. And it is also sad that
waste of time.' Then everybody can quietly believe that a) they they are wasting their valuable time which they could spend
are correct and b) other people are fools and c) they are creating something with Python. Moreover, for the Python community
undeniably fortunate to not have to share a lab with idiots, (which as a whole, from a public relations point of view, this is quite
is something the arguers could do _now_, but apparently have unfortunate. The people who aren't posting about tabs and spaces,
forgotten). 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 The problem is that there is no polite way to say 'Stop wasting
than whether it is too hostile for newcomers. Possibly somebody your valuable time and mine.' People who are already in the middle
could get around to explaining to me what is the difference between of a flame war are not well disposed to believe that you are acting
__getattr__ and __getattribute__ in non-Classic classes in 2.2, a out of compassion for them, and quite rightly insist that their own
question I have foolishly posted in the middle of the current tab time is their own to do with as they please. They are stuck like
thread. I would like to know the answer to that question.[2] flies in treacle in this wretched argument, and it is self-evident
that they cannot disengage or they would have already done so.
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 But today I had to spend time cleaning my keyboard because the 'n'
care. 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 References
==========
[1] PEP 1, PEP Purpose and Guidelines .. [1] PEP 1, PEP Purpose and Guidelines
http://www.python.org/dev/peps/pep-0001/ http://www.python.org/dev/peps/pep-0001/
[2] Tim Peters already has (private correspondence). My early 2.2 .. [2] Tim Peters already has (private correspondence). My early 2.2
didn't have a __getattribute__, and __getattr__ was didn't have a ``__getattribute__``, and ``__getattr__`` was
implemented like __getattribute__ now is. This has been implemented like ``__getattribute__`` now is. This has been
fixed. The important conclusion is that my Decorator Pattern fixed. The important conclusion is that my Decorator Pattern
is safe and all is right with the world. is safe and all is right with the world.
Copyright Copyright
=========
This document has been placed in the public domain. This document has been placed in the public domain.
Local Variables: ..
mode: indented-text Local Variables:
indent-tabs-mode: nil mode: indented-text
fill-column: 70 indent-tabs-mode: nil
End: fill-column: 70
End: