Input statement question

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • ron

    Input statement question



    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

    #2
    Re: Input statement question


    "ron" <radam2@tampaba y.rr.com> wrote in message
    news:1bripv431l fpjdgikhetc2fsb f8e7503ks@4ax.c om...[color=blue]
    >
    >
    > 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.[/color]

    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.
    [color=blue]
    > 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?[/color]
    [color=blue]
    > The fact that there needs to be a warning about the input() function
    > is indication to me that it may need to be changed.[/color]

    There's general agreement that it's a Bad Thing.
    [color=blue]
    > 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?[/color]

    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[color=blue]
    >
    >[/color]


    Comment

    Working...