I like the exact proposal made here better than any of the
alternatives mentioned so far.
- Against naming it readline(): the "real" readline doesn't strip the
\n and returns an empty string for EOF instead of raising EOFError; I
believe the latter is more helpful for true beginners' code.
- Against naming it ask() and renaming print() to say(): I find those
rather silly names that belong in toy or AI languages. Changing print
from statement to function maintains Pythonicity; renaming it say()
does not.
- I don't expect there will be much potential confusion with the 2.x
input(); that function is used extremely rarely. It will be trivial to
add rules to the refactoring tool (sandbox/2to3/) that replace input()
with eval(input()) and replace raw_input() with input().
--Guido
On 12/22/06, Andre Roberge <[EMAIL PROTECTED]> wrote:
> A few months ago, there was an active discussion on edu-sig regarding
> the proposed fate of raw_input(). The text below is an attempt at
> summarizing the discussion in the form of a tentative PEP.
> It is respectfully submitted for your consideration.
>
> If it is to be considered, in some form, as an official PEP, I have
> absolutely no objection for a regular python-dev contributor to take over
> the
> ownership/authorship.
>
> André Roberge
>
> -----------------------------------------------------------------
> PEP: XXX
> Title: Simple input built-in in Python 3000
> Version: $Revision: 0.2 $
> Last-Modified: $Date: 2006/12/22 10:00:00 $
> Author: André Roberge <andre.roberge at gmail.com >
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 13-Sep-2006
> Python-Version: 3.0
> Post-History:
>
> Abstract
> ========
>
> Input and output are core features of computer programs. Currently,
> Python provides a simple means of output through the print keyword
> and two simple means of interactive input through the input()
> and raw_input() built-in functions.
>
> Python 3.0 will introduces various incompatible changes with previous
> Python versions[1]. Among the proposed changes, print will become a
> built-in
> function, print(), while input() and raw_input() would be removed completely
> from the built-in namespace, requiring importing some module to provide
> even the most basic input capability.
>
> This PEP proposes that Python 3.0 retains some simple interactive user
> input capability, equivalent to raw_input(), within the built-in namespace.
>
> Motivation
> ==========
>
> With its easy readability and its support for many programming styles
> (e.g. procedural, object-oriented, etc.) among others, Python is perhaps
> the best computer language to use in introductory programming classes.
> Simple programs often need to provide information to the user (output)
> and to obtain information from the user (interactive input).
> Any computer language intended to be used in an educational setting should
> provide straightforward methods for both output and interactive input.
>
> The current proposals for Python 3.0 [1] include a simple output pathway
> via a built-in function named print(), but a more complicated method for
> input [e.g. via sys.stdin.readline()], one that requires importing an
> external
> module. Current versions of Python (pre-3.0) include raw_input() as a
> built-in function. With the availability of such a function, programs that
> require simple input/output can be written from day one, without requiring
> discussions of importing modules, streams, etc.
>
> Rationale
> =========
>
> Current built-in functions, like input() and raw_input(), are found to be
> extremely useful in traditional teaching settings. (For more details,
> see [2] and the discussion that followed.)
> While the BDFL has clearly stated [3] that input() was not to be kept in
> Python 3000, he has also stated that he was not against revising the
> decision of killing raw_input().
>
> raw_input() provides a simple mean to ask a question and obtain a response
> from a user. The proposed plans for Python 3.0 would require the
> replacement
> of the single statement
>
> name = raw_input("What is your name?")
>
> by the more complicated
>
> import sys
> print("What is your name?")
> same = sys.stdin.readline()
>
> However, from the point of view of many Python beginners and educators, the
> use of sys.stdin.readline() presents the following problems:
>
> 1. Compared to the name "raw_input", the name "sys.stdin.readline()"
> is clunky and inelegant.
>
> 2. The names "sys" and "stdin" have no meaning for most beginners,
> who are mainly interested in *what* the function does, and not *where*
> in the package structure it is located. The lack of meaning also makes
> it difficult to remember:
> is it "sys.stdin.readline()", or " stdin.sys.readline()"?
> To a programming novice, there is not any obvious reason to prefer
> one over the other. In contrast, functions simple and direct names like
> print, input, and raw_input, and open are easier to remember.
>
> 3. The use of "." notation is unmotivated and confusing to many beginners.
> For example, it may lead some beginners to think "." is a standard
> character that could be used in any identifier.
>
> 4. There is an asymmetry with the print function: why is print not called
> sys.stdout.print()?
>
>
> Specification
> =============
>
> The built-in input function should be totally equivalent to the existing
> raw_input() function.
>
> Open issues
> ===========
>
> With input() effectively removed from the language, the name raw_input()
> makes much less sense and alternatives should be considered. The
> various possibilities mentioned in various forums include:
>
> ask()
> ask_user()
> get_string()
> input() # rejected by BDFL
> prompt()
> read()
> user_input()
> get_response()
>
> While it has bee rejected by the BDFL, it has been suggested that the most
> direct solution would be to rename "raw_input" to "input" in Python 3000.
> The main objection is that Python 2.x already has a function named "input",
> and, even though it is not going to be included in Python 3000,
> having a built-in function with the same name but different semantics may
> confuse programmers migrating from 2.x to 3000. Certainly, this is no
> problem
> for beginners, and the scope of the problem is unclear for more experienced
> programmers, since raw_input(), while popular with many, is not in
> universal use. In this instance, the good it does for beginners could be
> seen to outweigh the harm it does to experienced programmers -
> although it could cause confusion for people reading older books or
> tutorials.
>
>
> References
> ==========
>
> .. [1] PEP 3100, Miscellaneous Python 3.0 Plans, Kuchling, Cannon
> (http://www.python.org/dev/peps/pep-3100/)
> .. [2] The fate of raw_input() in Python 3000
> (http://mail.python.org/pipermail/edu-sig/2006-September/006967.html)
> .. [3] Educational aspects of Python 3000
> (
> http://mail.python.org/pipermail/python-3000/2006-September/003589.html)
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000@python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
