Hi-all, Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision. This proposal could most certainly be strengthened, and the wording improved by a native English speaker with stronger CS background than I have. I have attempted to follow the standard recommended format (including providing both a motivation and rationale ... which seemed a bit redundant and an artificial split...) Feel free to make comments for improvement and even take over the "ownership" of this PEP. André ========================================= PEP: XXX Title: Simple input built-in in Python 3000 Version: $Revision: 0.1 $ Last-Modified: $Date: 2006/09/13 20:00:00 $ Author: André Roberge <andre.roberge@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 input throught 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 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 most often need to contain a means to provide information to a user (output) as well as obtaining information from that user (input). Any computer language intended to be used in an educational setting should provide straightforward methods for both input and output. 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 the discussion that followed [3].) 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 information from a user. The proposed plans for Python 3.0 would require the replacement of the single statement speed = raw_input("What is the average airspeed velocity of an unladed swallow?") by the more complicated import sys print("What is the average airspeed velocity of an unladed swallow?") speed = sys.stdin.readline() The removal of raw_input (or equivalent) would not significantly reduce the built-in namespace while it would steepen significantly the learning curve for beginners. 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 Guido prompt() read() user_input() References ========== .. [1] Miscellaneous Python 3.0 Plans (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.
Andre Roberge wrote:
Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision. ... Feel free to make comments for improvement and even take over the "ownership" of this PEP.
+1 Thanks for doing this, Andre. Vern -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
Andre Roberge wrote:
Hi-all,
Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision.
Looks great! You can add my name, if you like.
I'm glad you went to the work to make this a PEP. That's the way to go! I've interpersed my own views for the record, about why I think raw_input should go away. However, if I lose this little battle, I really won't mind too much. I don't think the success CP4E depends on it strongly, one way or the other.
This PEP proposes that Python 3.0 retains some simple user input capability, equivalent to raw_input(), within the built-in namespace.
In our intro classes, we have to import any namespace beyond what's in __builtins__ and beyond we've written during the session. Even if the target namespace in turns contains raw_input(), we still had to import that target program. Running Python programs from the command line is not the optimum place to begin with beginners, in our view. So we don't see the problem with importing sys.stdin.readline() if that's what our script is going to need. But "scripts" are not where we begin. A lot of the time, we simply feed arguments to functions interactively, in the context of a Python shell session. This approach, we feel, develops a stronger understanding of Python in our students, so we're glad raw_input is being demoted. That will discourage pedagogy which considers command line scripts from the operating system a beginner's environment.
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 most often need to contain a means to provide information to a user (output) as well as obtaining information from that user (input). Any computer language intended to be used in an educational setting should provide straightforward methods for both input and output.
def f(x): return x*x f(2) 4
is in not way "not straightforward". Input and output have both occured.
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.
Modules, aka namespaces, should be discussed very early. The shell is a boring place without import, a key word.
raw_input() provides a simple mean to ask a question and obtain information from a user. The proposed plans for Python 3.0 would require the replacement of the single statement
speed = raw_input("What is the average airspeed velocity of an unladed swallow?")
by the more complicated
import sys print("What is the average airspeed velocity of an unladed swallow?") speed = sys.stdin.readline()
However, if the source code is in front of you, self-prompting is less of a temptation. Just enter the speed in the source code or feed it to __init__. myswallow.velocity = 10
The removal of raw_input (or equivalent) would not significantly reduce the built-in namespace while it would steepen significantly the learning curve for beginners.
Especially if they're being taught the old fashioned way, based on *not* being in the shell and trying to write "scripts" for hypothetical end users who have no access to the source. In sum, raw_input() is mostly used as a crutch by those wedding to a particular pedagogical technique. Whereas I believe teachers have a right to develop their own style, I don't believe it's "the beginners" who are being protected by keeping raw_input as a __builtin__; in this case, I believe it's more teachers trying to stick to their old ways of teaching. Alternatives exist. Beginners need not suffer if raw_input goes to sys. i/o is not such a problem when you know how to work with a namespace directly. Kirby
Andre, Your English and your organization and rationale are excellent. I would be happy to be added as a signer. Thanks, Andrew Harrington Andre Roberge wrote:
Hi-all,
Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision.
This proposal could most certainly be strengthened, and the wording improved by a native English speaker with stronger CS background than I have. I have attempted to follow the standard recommended format (including providing both a motivation and rationale ... which seemed a bit redundant and an artificial split...) Feel free to make comments for improvement and even take over the "ownership" of this PEP.
André
========================================= PEP: XXX Title: Simple input built-in in Python 3000 Version: $Revision: 0.1 $ Last-Modified: $Date: 2006/09/13 20:00:00 $ Author: André Roberge <andre.roberge@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 input throught 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 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 most often need to contain a means to provide information to a user (output) as well as obtaining information from that user (input). Any computer language intended to be used in an educational setting should provide straightforward methods for both input and output.
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 the discussion that followed [3].) 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 information from a user. The proposed plans for Python 3.0 would require the replacement of the single statement
speed = raw_input("What is the average airspeed velocity of an unladed swallow?")
by the more complicated
import sys print("What is the average airspeed velocity of an unladed swallow?") speed = sys.stdin.readline()
The removal of raw_input (or equivalent) would not significantly reduce the built-in namespace while it would steepen significantly the learning curve for beginners.
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 Guido prompt() read() user_input()
References ==========
.. [1] Miscellaneous Python 3.0 Plans (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. _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- Andrew N. Harrington Computer Science Department Director of Academic Programs Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611
On 9/13/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Hi-all,
Replying to myself as I can`t single out an individual response... Thanks to all those that replied; it was nice to come back from a business trip and read so many positive messages :-) I also received a private email from Toby Donaldson who had started working on his own version of such a PEP, and shared it with me. In my opinion, (and I already wrote him to tell him so) Toby's PEP is much better written than mine and I hope he will soon share it with people on this list for feedback. The following step would then most likely be to post it on the python-3000 mailing list. André
Hi all- I finally got the time to do a follow-up on python-3000 based on my original message on edu-sig. Those interested can look it up here: http://mail.python.org/pipermail/python-3000/2006-December/005242.html As I don't subscribe to the python-3000 list, I probably won't do any follow-up; we'll see what comes out of the discussion. André On 9/13/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Hi-all,
Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision.
[snip]
My apologies to those that feel annoyed I reply to one of my own post (on December 22), without any other intervenor in between. The pre-PEP has received some attention, including some positive one from GvR. Those interested to see his initial response can see it here: http://mail.python.org/pipermail/python-3000/2006-December/005249.html Then, on December 23, he wrote: --------------- 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. --Guido --------------- I take this as a very positive sign. Unfortunately, there appear to have been no follow-up since. Perhaps it is because it was so late in the year, and when everyone came back, the issue had been forgotten. In any event, I plan to go to Pycon 2007 and, if it hasn't been followed-up by then, do some lobbying on behalf of all those on edu-sig who have manifested their support for this issue in the past. André P.S. Crunchy will be leading the way: I am planning to have support for input()/raw_input() in the next release, and the semantic will be that they will behave identically (i.e. return a string). It is already implemented for the embedded interpreter in svn. On 12/22/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Hi all-
I finally got the time to do a follow-up on python-3000 based on my original message on edu-sig.
Those interested can look it up here: http://mail.python.org/pipermail/python-3000/2006-December/005242.html
As I don't subscribe to the python-3000 list, I probably won't do any follow-up; we'll see what comes out of the discussion.
André
On 9/13/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Hi-all,
Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision.
[snip]
André, This is indeed good news and for my part seems to be the best solution. Thanks for putting together the proposal and lobbying on our behalf. See you at PyCon... :) Cheers, Vern Ceder Andre Roberge wrote:
My apologies to those that feel annoyed I reply to one of my own post (on December 22), without any other intervenor in between.
The pre-PEP has received some attention, including some positive one from GvR. Those interested to see his initial response can see it here:
http://mail.python.org/pipermail/python-3000/2006-December/005249.html
Then, on December 23, he wrote: --------------- 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.
--Guido ---------------
I take this as a very positive sign. Unfortunately, there appear to have been no follow-up since. Perhaps it is because it was so late in the year, and when everyone came back, the issue had been forgotten. In any event, I plan to go to Pycon 2007 and, if it hasn't been followed-up by then, do some lobbying on behalf of all those on edu-sig who have manifested their support for this issue in the past.
André
P.S. Crunchy will be leading the way: I am planning to have support for input()/raw_input() in the next release, and the semantic will be that they will behave identically (i.e. return a string). It is already implemented for the embedded interpreter in svn.
On 12/22/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Hi all-
I finally got the time to do a follow-up on python-3000 based on my original message on edu-sig.
Those interested can look it up here: http://mail.python.org/pipermail/python-3000/2006-December/005242.html
As I don't subscribe to the python-3000 list, I probably won't do any follow-up; we'll see what comes out of the discussion.
André
On 9/13/06, Andre Roberge <andre.roberge@gmail.com> wrote:
Hi-all,
Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision.
[snip]
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
participants (5)
-
Andre Roberge -
Andrew Harrington -
kirby urner -
Peter Chase -
Vern Ceder