On 4-Sep-06, at 5:45 PM, Andre Roberge wrote:
The following is something I have been pondering for quite a while now and am wondering what other people on this list think.
According to PEP 3100 (http://www.python.org/dev/peps/pep-3100/ ) raw_input() [as well as input()] is recommended for removal from the built-in namespace, to be replaced by sys.stdin.readline().
But it is trivial to add this back in:
raw_input = sys.stdin.readline
While I don't think anyone can argue that this removal makes a major difference for Python as a programming language, I believe it makes a significant difference for using Python as a learning language, adding a non-trivial barrier to learning.
Removing this from built-ins isn't going to be any more confusing or off-putting than trying to understand the difference between input and raw_input in the first place. I remember being tripped up by *that* when I was first learning Python.
Consider the following fake sessions at the interpreter prompt, where I use extra parentheses to turn print as a function (as is also proposed in Python 3000) - these parentheses can of course be used with today's Python.
The standard prompt is great, but not the best learning environment. I would recommend that students use IPython instead, and since IPython already adds lots of convenience methods to the global namespace, there's nothing to stop it from pre-populating globals with input and raw_input. That is: 1. It isn't necessary for global functions at the command-line prompt to be in builtins 2. It possible (and desirable) to have different command-line prompts for different purposes 3. It isn't necessary to clutter the builtins with every convenience function, even if we're used to it Now, all that given, I do hope Python doesn't start going down the road that Java has taken and replace
open('myfilename.txt')
with
open(BufferedStream(InputStream(FileStream('myfilename.txt')
but I don't think the loss of raw_input is quite on that scale. --Dethe Art is either plagiarism or revolution. --Paul Gauguin