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)
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 <module> 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 <module> 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:

153
pep-0229.txt
View File

@ -5,116 +5,123 @@ Last-Modified: $Date$
Author: A.M. Kuchling <amk@amk.ca>
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:

114
pep-0240.txt
View File

@ -2,94 +2,108 @@ PEP: 240
Title: Adding a Rational Literal to Python
Version: $Revision$
Last-Modified: $Date$
Author: Christopher A. Craig <python-pep@ccraig.org>,
Moshe Zadka <moshez@zadka.site.co.il>
Author: Christopher A. Craig <python-pep@ccraig.org>, Moshe Zadka <moshez@zadka.site.co.il>
Status: Rejected
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Mar-2001
Python-Version: 2.2
Post-History: 16-Mar-2001
Abstract
========
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:

151
pep-0277.txt
View File

@ -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:

152
pep-0286.txt
View File

@ -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:

183
pep-0295.txt
View File

@ -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:

139
pep-0297.txt
View File

@ -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:

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>
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:

150
pep-0341.txt
View File

@ -5,46 +5,61 @@ Last-Modified: $Date$
Author: Georg Brandl <georg@python.org>
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:
<do something>
except Exception:
<handle the error>
finally:
<cleanup>
try:
<do something>
except Exception:
<handle the error>
finally:
<cleanup>
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:
<suite 1>
except Ex1:
<suite 2>
<more except: clauses>
else:
<suite 3>
finally:
<suite 4>
be exactly the same as the legacy::
try:
try:
<suite 1>
except Ex1:
@ -52,72 +67,65 @@ Rationale/Proposal
<more except: clauses>
else:
<suite 3>
finally:
<suite 4>
finally:
<suite 4>
be exactly the same as the legacy
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.
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:

152
pep-0666.txt
View File

@ -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: