Input statement question

[John Roth]

"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.

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.

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
>
>