>>>>> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> That would assume that the user knows that exit is a
Martin> function: apparently, people expect it to be a statement
Martin> (like print),
Oh, the irony of that analogy!<wink>
Martin> or they are entirely unaware of the distinctions between
Martin> statements, expressions, and functions.
Then there's little point to giving them access to the interpreter!
Of course, Martin also mentioned "students". Python is not the only
language in the world; we all know that, even if most of us much
prefer programming in Python to any other environment. If you're
teaching, why not use this as an opportunity to deliver a brief
lecture on why Python does things differently, and why one should
understand a _formal_ language in its own terms, not in terms of what
you (the user/programmer) want it to be for momentary convenience?
My feeling is that the current behavior of "exit" and "quit" is not
"you didn't say please" but "excuse me, I don't speak BASIC; would you
say that in Python or signal that the conversation is over (ie, EOF)?"
For me, that's part of the Zen of Python. Probably I'm just missing
something given the amount of support this idea is getting, from
really respectable sources, too, but it just seems wrong to change
this. What's wrong with having a distinctive personality?
I suppose the current value of those variables sounds a bit rude. Why
not fix the discourtesy, rather than what's not broken (IMHO)?
exit = """\
The Python interpreter simply interprets a Python program. It provides
no special interactive commands. The line editor is a thin front-end
to the standard input stream. To exit your program, use one of the
functions or exceptions provided for this purpose, or simply end the
file (interactively this is signaled by Ctrl-D).
This public service message brought to you by the global variable 'exit'."""
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
