Input statement question

Discussion in 'Python' started by ron, Oct 24, 2003.

  1. ron

    ron Guest

    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?
     
    ron, Oct 24, 2003
    #1
    1. Advertising

  2. ron

    John Roth Guest

    "ron" <> wrote in message
    news:...
    >
    >
    > 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
    >
    >
     
    John Roth, Oct 25, 2003
    #2
    1. Advertising

  3. ron

    ron Guest

    On Sat, 25 Oct 2003 11:16:50 -0400, (Mel Wilson)
    wrote:

    >In article <>,
    >ron <> wrote:
    >>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, Oct 25, 2003
    #3
  4. ron

    ron Guest

    On Sat, 25 Oct 2003 14:14:36 -0400, "John Roth"
    <> wrote:

    >
    >"ron" <> wrote in message
    >news:...
    >>
    >>
    >> 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
     
    ron, Oct 26, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    807
  2. Jay McGavren
    Replies:
    11
    Views:
    1,144
    Alan Krueger
    Jan 16, 2006
  3. tedsuzman
    Replies:
    2
    Views:
    7,094
    Michel Claveau, résurectionné d'outre-bombe inform
    Jul 21, 2004
  4. Ted
    Replies:
    1
    Views:
    470
    Duncan Booth
    Jul 22, 2004
  5. Replies:
    21
    Views:
    1,060
    Giannis Papadopoulos
    Aug 2, 2005
Loading...

Share This Page