Input statement question

[ron]

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.

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.

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?

 

[John Roth]

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

 

[ron]

Is the input() function new? There doesn't seem to be very many
examples of it's use.
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?

It does seem a bit strange. In a statically typed
language it seems sensible to have a function that could
parse input and return an object of the type the program
demands. Python being dynamically typed, you can argue,
means that the object type matches the input, regardless of
what the program expects. But that's the strange part.

I've never used `input` in a real program. (It's not new
.. quite the contrary, AFAIK)

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'] )

This is problematic. In a situation where I'm concerned
with a variety of terminate characters, I'm also concerned
with the chance of missing terminate characters. So if my
input routine skips a few '%' in search of a '$' that isn't
there, I'm <expletive deleted>.

Why would that be a problem? You would just get the whole input
stream. The only problem I see with this is if you are getting input
from a user and don't tell the user what the new terminating character
is. Input from a file would terminate naturally at EOF or at a
specified character if someone finds that is useful. (?)

Python file input seems to be moving in the direction of
files of records, where the default record is a text line.
In non-default situations, you'll subclass the `file`
class to pick out records according to your need.

Regards. Mel.

In the case of files, a regular file i/o routine would probably be
better in most cases. And the need for raw text input from a user is
probably only needed in special cases.

Actually I think the best way to get that sort of entry from a user is
to use a key press input function.

In the case of people, I think an input() function designed to work
with people has advantages. Just like a file io routine designed to
work with files works best there.

Ron

 

[ron]

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