Input statement question

[ron]

On Sat, 25 Oct 2003 14:14:36 -0400, "John Roth"
<newsgroups at jhrothjr.com> wrote:

>
>"ron" <radam2 at tampabay.rr.com> wrote in message
>news:1bripv431lfpjdgikhetc2fsbf8e7503ks at 4ax.com...
>>
>>
>> Hi, I'm still new at Python and have been away from programming for a
>> number of years in general.  I apologized in advance if this has been
>> discussed extensively already.
>>
>>
>> Is the input() function new?  There doesn't seem to be very many
>> examples of it's use.
>
>No, it's been around for a long time, I suspect from the beginning.
>I believe it's on the BDFL's list of features he'd rather not have
>made a built-in, but it's not going to go away until Python 3.0.
>
>> After a lot of searching I did find both the input() and raw_input()
>> statement definitions.  I don't understand the reasoning behind making
>> input() equivalent to  "eval (raw_imput[prompt])"  the default
>> behavior, and "raw_input([prompt])" input standard strings?
>
>> The fact that there needs to be a warning about the input() function
>> is indication to me that it may need to be changed.
>
>There's general agreement that it's a Bad Thing.
>
>> It seems to me, input() should get a standard string as the default
>> behavior.   And raw input should get strings + control characters
>> until the specified ending character is received.
>>
>> variable = input_raw( ['terminate character'] [,'file'] )
>>
>> The new line character could be the default termination character, the
>> programmer could change it to something else.  And the file argument
>> would compliment the enhanced print '>>' operations.  The input should
>> always be a string.  Eval should be used separately on it if it is
>> desired.  With the above statement you may be able to input multiple
>> lines and evaluate them as a set.  Of course, maybe a syntax_check()
>> function would be worth while before using the eval() function.
>>
>> And a regular standard input function would could be...
>>
>> variable = input( ['prompt'] [,'format'] [,'file'] )
>>
>> Where prompt is a string,  format is a regular expression string
>> indicating valid input characters, and file is an alternate input
>> source.
>>
>> By surrounding the input() with int() or float(), the pre formatted
>> result can convert it to a numeric format with out errors.
>>
>> I know there are probably libraries I can import to get these
>> capabilities.  I've just started to explore some of them.  This just
>> seems to be such a basic operations that I think it should be built
>> in.  Maybe it is and I haven't found it yet?
>
>I don't think you're going to get much traction on this suggestion.
>In the last few years, the Python maintainers have gone to wanting
>believable use cases for features that aren't blindingly obvious, and
>this one isn't in that category.

Hmmm....  (?)   Excuse me for not following what you mean here. 

I find it hard to believe a  well designed general purpose console
input function is not a "believable use case" feature  for a scripting
language whose primary output and input mode is a text console window.

>The history of PEP 289 is a good example of this. It was originally
>rejected because of poor syntax and a lack of use cases. It was
>recently revived with much better syntax and a small boatload of
>use cases, and it looks like it's on the fast path to being included
>into 2.4.

What does generator expressions have to do with user console input?

>So, what's the actual use case? How frequent is it? If you did
>a scan of the Python library, how many places would you find
>it useful. Hint: it's going to be close to zero. The only reason
>I don't say zero is that it might be useful in situations like pyExpect.
>
>John Roth

A raw input routine is probably not needed.  A keypress scan routine
can easily do that.   Is there one?

But I do think that a well designed console input routing is very
useful.  I think one of the reasons the existing input() function is
not used more is because the existing function is so limited.  And
possibly the warning/eval issue and non-intuitive "raw_" prefix.  If
anything, the current low usage of this item indicates it can be
changed with a low incidence of breaking existing programs.

A better way to measure demand for this  feature is to look at other
console mode programming languages.  I think  you will find the use of
formated user input much more prevalent.  

User input is very different from file input in that it works best
when you give immediate feed back to the user.  An example is, not
accepting letters when numbers are wanted, or only accepting numbers
or text  in a particular format.  Yes, I can do all of this with a key
press routine and testing each key press.  I've done that before.  Or
I can repeatedly ask the user to reenter data till they get it
correct.  Which is not user friendly and requires additional code to
test the input.  Testing for valid user input should always be done so
why not build it into the input() function?  Now getting data from a
user is easier for both the programmer and the person who is using the
program.

To say features like this are unimportant is, IMHO, like saying print
formatting features are also unimportant.   Program output is such a
useful feature it's worth having a well defined print command built
in.  I believe a powerful user input function would also be valuable
and should be built in for the same reasons.

_Ron  Adam