[Python-checkins] r45935 - peps/trunk/pep-0359.txt peps/trunk/pep-3002.txt
steven.bethard
python-checkins at python.org
Mon May 8 04:20:02 CEST 2006
Author: steven.bethard
Date: Mon May 8 04:20:01 2006
New Revision: 45935
Modified:
peps/trunk/pep-0359.txt
peps/trunk/pep-3002.txt
Log:
PEP 359 withdrawn at Guido's request.
PEP 3002 to require that all backwards incompatible changes be accompanied by a patch to Python 2.X that issues appropriate warnings when --python3 is specified.
Modified: peps/trunk/pep-0359.txt
==============================================================================
--- peps/trunk/pep-0359.txt (original)
+++ peps/trunk/pep-0359.txt Mon May 8 04:20:01 2006
@@ -3,7 +3,7 @@
Version: $Revision$
Last-Modified: $Date$
Author: Steven Bethard <steven.bethard at gmail.com>
-Status: Draft
+Status: Withdrawn
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
@@ -43,6 +43,15 @@
python-dev list.
+Withdrawal Notice
+=================
+
+This PEP was withdrawn at Guido's request [2]_. Guido didn't like it,
+and in particular didn't like how the property use-case puts the
+instance methods of a property at a different level than other
+instance methods and requires fixed names for the property functions.
+
+
Motivation
==========
@@ -170,7 +179,7 @@
Since descriptors are used to customize access to an attribute, it's
often useful to know the name of that attribute. Current Python
doesn't give an easy way to find this name and so a lot of custom
-descriptors, like Ian Bicking's setonce descriptor [2]_, have to hack
+descriptors, like Ian Bicking's setonce descriptor [3]_, have to hack
around this somehow. With the make-statement, you could create a
``setonce`` attribute like::
@@ -227,7 +236,7 @@
...
x = property(get_x, set_x, "the x of the frobulation")
-This issue has been brought up before, and Guido [3]_ and others [4]_
+This issue has been brought up before, and Guido [4]_ and others [5]_
have briefly mused over alternate property syntaxes to make declaring
properties easier. With the make-statement, the following syntax
could be supported::
@@ -255,7 +264,7 @@
Example: interfaces
-------------------
-Guido [5]_ and others have occasionally suggested introducing
+Guido [6]_ and others have occasionally suggested introducing
interfaces into python. Most suggestions have offered syntax along
the lines of::
@@ -304,7 +313,7 @@
The ``<tuple>`` expression is optional; if not present, an empty tuple
will be assumed.
-A patch is available implementing these semantics [6]_.
+A patch is available implementing these semantics [7]_.
The make-statement introduces a new keyword, ``make``. Thus in Python
2.6, the make-statement will have to be enabled using ``from
@@ -319,8 +328,8 @@
Does the ``make`` keyword break too much code? Originally, the make
statement used the keyword ``create`` (a suggestion due to Nick
-Coghlan). However, investigations into the standard library [7]_ and
-Zope+Plone code [8]_ revealed that ``create`` would break a lot more
+Coghlan). However, investigations into the standard library [8]_ and
+Zope+Plone code [9]_ revealed that ``create`` would break a lot more
code, so ``make`` was adopted as the keyword instead. However, there
are still a few instances where ``make`` would break code. Is there a
better keyword for the statement?
@@ -464,7 +473,7 @@
And if the repetition of the element names here is too much of a DRY
violoation, it is also possible to eliminate all as-clauses except for
-the first by adding a few methods to Element. [9]_
+the first by adding a few methods to Element. [10]_
So are there real use-cases for executing the block in a dict of a
different type? And if so, should the make-statement be extended to
@@ -530,28 +539,31 @@
.. [1] Michele Simionato's original suggestion
(http://mail.python.org/pipermail/python-dev/2005-October/057435.html)
-.. [2] Ian Bicking's setonce descriptor
+.. [2] Guido requests withdrawal
+ (http://mail.python.org/pipermail/python-3000/2006-April/000936.html)
+
+.. [3] Ian Bicking's setonce descriptor
(http://blog.ianbicking.org/easy-readonly-attributes.html)
-.. [3] Guido ponders property syntax
+.. [4] Guido ponders property syntax
(http://mail.python.org/pipermail/python-dev/2005-October/057404.html)
-.. [4] Namespace-based property recipe
+.. [5] Namespace-based property recipe
(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418)
-.. [5] Python interfaces
+.. [6] Python interfaces
(http://www.artima.com/weblogs/viewpost.jsp?thread=86641)
-.. [6] Make Statement patch
+.. [7] Make Statement patch
(http://ucsu.colorado.edu/~bethard/py/make_statement.patch)
-.. [7] Instances of create in the stdlib
+.. [8] Instances of create in the stdlib
(http://mail.python.org/pipermail/python-list/2006-April/335159.html)
-.. [8] Instances of create in Zope+Plone
+.. [9] Instances of create in Zope+Plone
(http://mail.python.org/pipermail/python-list/2006-April/335284.html)
-.. [9] Eliminate as-clauses in with-statement XML
+.. [10] Eliminate as-clauses in with-statement XML
(http://mail.python.org/pipermail/python-list/2006-April/336774.html)
Modified: peps/trunk/pep-3002.txt
==============================================================================
--- peps/trunk/pep-3002.txt (original)
+++ peps/trunk/pep-3002.txt Mon May 8 04:20:01 2006
@@ -86,60 +86,25 @@
============================
In addition to the PEP requirement, backwards incompatible changes to
-Python must also be accompanied by code that can identify pieces of
-Python 2.X code that may be problematic in Python 3.0.
-
-This PEP proposes to house this code in tools/scripts/python3warn.py.
-Thus PEPs for backwards incompatible changes should include a patch to
-this file that produces the appropriate warnings. Code in
-python3warn.py should be written to the latest version of Python 2.X
-(not Python 3000) so that Python 2.X users will be able to run the
-program without having Python 3000 installed.
-
-Currently, it seems too stringent to require that the code in
-python3warn.py identify all changes perfectly. Thus it is permissable
-if a backwards-incompatible PEP's python3warn.py code produces a
-number of false-positives (warning that a piece of code might be
-invalid in Python 3000 when it's actually still okay). However,
-false-negatives (not issuing a warning for code that will do the
-wrong thing in Python 3000) should be avoided whenever possible --
-users of python3warn.py should be reasonably confident that they have
-been warned about the vast majority of incompatibilities.
-
-So for example, a PEP proposing that ``dict.items()`` be modified to
-return an iterator instead of a list might add code like the following
-to python3warn.py::
-
- items_in_for = re.compile(r'for\s+\w+\s+in\s+\w+\.items\(\):')
- ...
- for i, line in enumerate(file_lines):
- ...
- if '.items()' in line and not items_in_for.search(line):
- message = 'dict.items() call may expect list at line %i'
- warnings.warn(message % i)
-
-This would issue a warning any time a ``.items()`` method was called
-and not immediately iterated over in a for-loop. Clearly this will
-issue a number of false-positive warnings (e.g. ``d2 =
-dict(d.items())``), but the number of false-negative warnings should
-be relatively low.
-
-
-Optional Extensions
-===================
-
-Instead of the python3warn.py script, a branch of Python 3000 could be
-maintained that added warnings at all the appropriate points in the
-code-base. PEPs proposing backwards-incompatible changes would then
-provide patches to the Python-3000-warn branch instead of to
-python3warn.py. With such a branch, the warnings issued could be
-near-perfect and Python users could be confident that their code was
-correct Python 3000 code by first running it on the Python-3000-warn
-branch and fixing all the warnings.
-
-At the moment, however, this PEP opts for the weaker measure
-(python3warn.py) as it is expected that maintaining a Python-3000-warn
-branch will be too much of a time drain.
+Python must also be accompanied by code to issue warnings for pieces
+of Python 2.X code that will behave differently in Python 3000. Such
+warnings will be enabled in Python 2.X using a new command-line
+switch: --python3. All backwards incompatible changes should be
+accompanied by a patch for Python 2.X that, when --python3 is
+specified, issues warnings for each construct that is being changed.
+
+For example, if ``dict.keys()`` returns an iterator in Python 3000,
+the patch to the Python 2.X branch should do something like:
+
+ If --python3 was specified, change ``dict.keys()`` to return a
+ subclass of ``list`` that issues warnings whenever you use any
+ methods other than ``__iter__()``.
+
+Such a patch would mean that warnings are only issued when features
+that will not be present in Python 3000 are used, and almost all
+existing code should continue to work. (Code that relies on
+``dict.keys()`` always returning a ``list`` and not a subclass should
+be pretty much non-existent.)
References
More information about the Python-checkins
mailing list