Input statement question

Mel Wilson mwilson at the-wire.com
Sat Oct 25 11:16:50 EDT 2003


In article <1bripv431lfpjdgikhetc2fsbf8e7503ks at 4ax.com>,
ron <radam2 at tampabay.rr.com> 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>.

   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.




More information about the Python-list mailing list