Any possibility that (some of) the following can be done before Pycon? Respectfully yours, André Roberge
On 12/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: [http://mail.python.org/pipermail/python-3000/2006-December/005257.html] > BTW, can someone clean up and check in the proto-PEP and start working > on an implementation or patch? Should be really simple. I'd like to > see a patch for the refactoring tool (sandbox/2to3) as well. This was as a follow up to: http://mail.python.org/pipermail/python-3000/2006-December/005249.html On 12/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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
