[Python-checkins] r55030 - peps/trunk/pep-0000.txt peps/trunk/pep-3125.txt peps/trunk/pep-3126.txt
guido.van.rossum
python-checkins at python.org
Tue May 1 01:03:43 CEST 2007
Author: guido.van.rossum
Date: Tue May 1 01:03:34 2007
New Revision: 55030
Added:
peps/trunk/pep-3125.txt (contents, props changed)
peps/trunk/pep-3126.txt (contents, props changed)
Modified:
peps/trunk/pep-0000.txt
Log:
Two new peps:
S 3125 Remove Backslash Continuation Jewett
S 3126 Remove Implicit String Concatenation Jewett
Modified: peps/trunk/pep-0000.txt
==============================================================================
--- peps/trunk/pep-0000.txt (original)
+++ peps/trunk/pep-0000.txt Tue May 1 01:03:34 2007
@@ -121,6 +121,8 @@
S 3121 Module Initialization and finalization von Löwis
S 3123 Making PyObject_HEAD conform to standard C von Löwis
S 3124 Overloading, Generic Functions, Interfaces Eby
+ S 3125 Remove Backslash Continuation Jewett
+ S 3126 Remove Implicit String Concatenation Jewett
S 3141 A Type Hierarchy for Numbers Yasskin
Finished PEPs (done, implemented in Subversion)
@@ -484,6 +486,8 @@
SR 3122 Delineation of the main module Cannon
S 3123 Making PyObject_HEAD conform to standard C von Löwis
S 3124 Overloading, Generic Functions, Interfaces Eby
+ S 3125 Remove Backslash Continuation Jewett
+ S 3126 Remove Implicit String Concatenation Jewett
S 3141 A Type Hierarchy for Numbers Yasskin
Added: peps/trunk/pep-3125.txt
==============================================================================
--- (empty file)
+++ peps/trunk/pep-3125.txt Tue May 1 01:03:34 2007
@@ -0,0 +1,103 @@
+PEP: 3125
+Title: Remove Backslash Continuation
+Version: $Revision$
+Last-Modified: $Date$
+Author: Jim J. Jewett <JimJJewett at gmail.com>
+Status: Draft
+Type: Standards Track
+Content-Type: text/plain
+Created: 29-Apr-2007
+Post-History: 29-Apr-2007, 30-Apr-2007
+
+
+Abstract
+
+ Python initially inherited its parsing from C. While this has
+ been generally useful, there are some remnants which have been
+ less useful for python, and should be eliminated.
+
+ This PEP proposes elimination of terminal "\" as a marker for
+ line continuation.
+
+
+Rationale for Removing Explicit Line Continuation
+
+ A terminal "\" indicates that the logical line is continued on the
+ following physical line (after whitespace).
+
+ Note that a non-terminal "\" does not have this meaning, even if the
+ only additional characters are invisible whitespace. (Python depends
+ heavily on *visible* whitespace at the beginning of a line; it does
+ not otherwise depend on *invisible* terminal whitespace.) Adding
+ whitespace after a "\" will typically cause a syntax error rather
+ than a silent bug, but it still isn't desirable.
+
+ The reason to keep "\" is that occasionally code looks better with
+ a "\" than with a () pair.
+
+ assert True, (
+ "This Paren is goofy")
+
+ But realistically, that parenthesis is no worse than a "\". The
+ only advantage of "\" is that it is slightly more familiar to users of
+ C-based languages. These same languages all also support line
+ continuation with (), so reading code will not be a problem, and
+ there will be one less rule to learn for people entirely new to
+ programming.
+
+
+Alternate proposal
+
+ Several people have suggested alternative ways of marking the line
+ end. Most of these were rejected for not actually simplifying things.
+
+ The one exception was to let any unfished expression signify a line
+ continuation, possibly in conjunction with increased indentation
+
+ assert True, # comma implies tuple implies continue
+ "No goofy parens"
+
+ The objections to this are:
+
+ - The amount of whitespace may be contentious; expression
+ continuation should not be confused with opening a new
+ suite.
+
+ - The "expression continuation" markers are not as clearly marked
+ in Python as the grouping punctuation "(), [], {}" marks are.
+
+ "abc" + # Plus needs another operand, so it continues
+ "def"
+
+ "abc" # String ends an expression, so
+ + "def" # this is a syntax error.
+
+ - Guido says so. [1] His reasoning is that it may not even be
+ feasible. (See next reason.)
+
+ - As a technical concern, supporting this would require allowing
+ INDENT or DEDENT tokens anywhere, or at least in a widely
+ expanded (and ill-defined) set of locations. While this is
+ in some sense a concern only for the internal parsing
+ implementation, it would be a major new source of complexity. [1]
+
+
+References
+
+ [1] PEP 30XZ: Simplified Parsing, van Rossum
+ http://mail.python.org/pipermail/python-3000/2007-April/007063.html
+
+
+Copyright
+
+ 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:
Added: peps/trunk/pep-3126.txt
==============================================================================
--- (empty file)
+++ peps/trunk/pep-3126.txt Tue May 1 01:03:34 2007
@@ -0,0 +1,112 @@
+PEP: 3126
+Title: Remove Implicit String Concatenation
+Version: $Revision$
+Last-Modified: $Date$
+Author: Jim J. Jewett <JimJJewett at gmail.com>
+Status: Draft
+Type: Standards Track
+Content-Type: text/plain
+Created: 29-Apr-2007
+Post-History: 29-Apr-2007, 30-Apr-2007
+
+
+Abstract
+
+ Python initially inherited its parsing from C. While this has
+ been generally useful, there are some remnants which have been
+ less useful for python, and should be eliminated.
+
+ This PEP proposes to eliminate Implicit String concatenation
+ based on adjacency of literals.
+
+ Instead of
+
+ "abc" "def" == "abcdef"
+
+ authors will need to be explicit, and add the strings
+
+ "abc" + "def" == "abcdef"
+
+
+Rationale for Removing Implicit String Concatenation
+
+ Implicit String concatentation can lead to confusing, or even
+ silent, errors.
+
+ def f(arg1, arg2=None): pass
+
+ f("abc" "def") # forgot the comma, no warning ...
+ # silently becomes f("abcdef", None)
+
+ or, using the scons build framework,
+
+ sourceFiles = [
+ 'foo.c'
+ 'bar.c',
+ #...many lines omitted...
+ 'q1000x.c']
+
+ It's a common mistake to leave off a comma, and then scons complains
+ that it can't find 'foo.cbar.c'. This is pretty bewildering behavior
+ even if you *are* a Python programmer, and not everyone here is. [1]
+
+ Note that in C, the implicit concatenation is more justified; there
+ is no other way to join strings without (at least) a function call.
+
+ In Python, strings are objects which support the __add__ operator;
+ it is possible to write:
+
+ "abc" + "def"
+
+ Because these are literals, this addition can still be optimized
+ away by the compiler. (The CPython compiler already does. [2])
+
+ Guido indicated [2] that this change should be handled by PEP, because
+ there were a few edge cases with other string operators, such as the %.
+ (Assuming that str % stays -- it may be eliminated in favor of
+ PEP 3101 -- Advanced String Formatting. [3] [4])
+
+ The resolution is to treat them the same as today.
+
+ ("abc %s def" + "ghi" % var) # fails like today.
+ # raises TypeError because of
+ # precedence. (% before +)
+
+ ("abc" + "def %s ghi" % var) # works like today; precedence makes
+ # the optimization more difficult to
+ # recognize, but does not change the
+ # semantics.
+
+ ("abc %s def" + "ghi") % var # works like today, because of
+ # precedence: () before %
+ # CPython compiler can already
+ # add the literals at compile-time.
+
+
+References
+
+ [1] Implicit String Concatenation, Jewett, Orendorff
+ http://mail.python.org/pipermail/python-ideas/2007-April/000397.html
+
+ [2] Reminder: Py3k PEPs due by April, Hettinger, van Rossum
+ http://mail.python.org/pipermail/python-3000/2007-April/006563.html
+
+ [3] PEP 3101, Advanced String Formatting, Talin
+ http://www.python.org/peps/pep-3101.html
+
+ [4] ps to question Re: Need help completing ABC pep, van Rossum
+ http://mail.python.org/pipermail/python-3000/2007-April/006737.html
+
+Copyright
+
+ 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:
More information about the Python-checkins
mailing list