Why should input(prompt="hello:") fail?

[zhi]

Really confused, when I use keyword style argument as following:
[color=blue][color=green][color=darkred]
>>> input(prompt="h ello")[/color][/color][/color]

Traceback (most recent call last):
File "<pyshell#5 2>", line 1, in -toplevel-
input(prompt="h ello")
TypeError: input() takes no keyword arguments

While the library reference says the function is: input( [prompt])
so, it should work.:(

I am using python 2.3 for windows.
Have anyone tried this?
I am new to python, please help me, thanks.

[Peter Hansen]

Re: Why should input(prompt=&q uot;hello:&quot ;) fail?

zhi wrote:[color=blue]
>
> Really confused, when I use keyword style argument as following:
>[color=green][color=darkred]
> >>> input(prompt="h ello")[/color][/color]
>
> Traceback (most recent call last):
> File "<pyshell#5 2>", line 1, in -toplevel-
> input(prompt="h ello")
> TypeError: input() takes no keyword arguments
>
> While the library reference says the function is: input( [prompt])
> so, it should work.:([/color]

No, it shouldn't. The argument is not shown with a name, so you
are supposed to use just a position argument, as in input('hello').

Note however that input() is a poor choice for serious work: you
should quickly get past the point of wanting to use it and learn
why raw_input() is a better choice.

-Peter

[Michael Hudson]

Re: Why should input(prompt=&q uot;hello:&quot ;) fail?

wongwung@hotmai l.com (zhi) writes:
[color=blue]
> Really confused, when I use keyword style argument as following:[/color]

Often builtin functions don't take keyword arguments. There's been a
gentle move towards supporting them over the years, but there are
many, many places that haven't been reached.

Cheers,
mwh

--
Usenet is like a herd of performing elephants with diarrhea --
massive, difficult to redirect, awe-inspiring, entertaining, and
a source of mind-boggling amounts of excrement when you least
expect it. -- spaf (1992)

[djw]

Re: Why should input(prompt=&q uot;hello:&quot ;) fail?

Peter Hansen wrote:
[color=blue]
> zhi wrote:[color=green]
>>
>> Really confused, when I use keyword style argument as following:
>>[color=darkred]
>> >>> input(prompt="h ello")[/color]
>>
>> Traceback (most recent call last):
>> File "<pyshell#5 2>", line 1, in -toplevel-
>> input(prompt="h ello")
>> TypeError: input() takes no keyword arguments
>>
>> While the library reference says the function is: input( [prompt])
>> so, it should work.:([/color]
>
> No, it shouldn't. The argument is not shown with a name, so you
> are supposed to use just a position argument, as in input('hello').
>
> Note however that input() is a poor choice for serious work: you
> should quickly get past the point of wanting to use it and learn
> why raw_input() is a better choice.
>
> -Peter[/color]

Doesn't this have more to do with the difference between C-based and Python
based modules in the std. lib?

Discussion on this topic:

http://tinyurl.com/wcgn

My spot checking indicates that you can use keyword args as shown in the
documentation, as long as its a Python based module. C-based modules seem
to be hit-or-miss, some support it, some don't. I actually think this could
be an improvement to the docs - actually show the way the function is
defined so that it is clear what (if any) keyword args are possible.

The docs are ambiguous about this currently, for example, in builtins:

# Function as shown in docs:
cmp(x,y)
[color=blue][color=green][color=darkred]
>>> cmp(x=1,y=2)[/color][/color][/color]
TypeError: cmp() takes no keyword arguments

(I would assume that cmp() has a C implementation? )

In calendar:

# Function as shown in docs:
leapdays(y1,y2)
[color=blue][color=green][color=darkred]
>>> calendar.leapda ys(y2=2004,y1=2 003)[/color][/color][/color]
0

I agree that for standard, heavily used functions/methods, this is probably
OK, but it does seem rather inconsistent. Certainly for single parameter
methods like the OP asked about (input()), having a keyword adds very
little value.

-Don

[Peter Hansen]

Re: Why should input(prompt=&q uot;hello:&quot ;) fail?

djw wrote:[color=blue]
>
> Peter Hansen wrote:
>[color=green]
> > zhi wrote:[color=darkred]
> >>
> >> Really confused, when I use keyword style argument as following:
> >>
> >> >>> input(prompt="h ello")
> >>
> >> Traceback (most recent call last):
> >> File "<pyshell#5 2>", line 1, in -toplevel-
> >> input(prompt="h ello")
> >> TypeError: input() takes no keyword arguments
> >>
> >> While the library reference says the function is: input( [prompt])
> >> so, it should work.:([/color]
> >
> > No, it shouldn't. The argument is not shown with a name, so you
> > are supposed to use just a position argument, as in input('hello').
> >
> > Note however that input() is a poor choice for serious work: you
> > should quickly get past the point of wanting to use it and learn
> > why raw_input() is a better choice.
> >
> > -Peter[/color]
>
> Doesn't this have more to do with the difference between C-based and Python
> based modules in the std. lib?[/color]

Yes, no... *if* the input() function supported keyword arguments, then
of course it would respond to a keyword argument of the correct name.

Since it doesn't, you can't exactly say that the name "prompt" is the
proper one to use. For a Python function, you would of course be able
to go and check the source and, if it used "prompt" for the name of its
sole positional argument, then you could use that name as a keyword
argument as well. For the builtin, I think the keyword argument support
has to be provided explicitly, as Michael Hudson is, I think, saying.

-Peter

[Mel Wilson]

input exploit, was: Why should input(prompt=&q uot;hello:&quot ;) fail?

In article <3FC23B46.8E2BF 00B@engcorp.com >,
Peter Hansen <peter@engcorp. com> wrote:[color=blue]
>Note however that input() is a poor choice for serious work: you
>should quickly get past the point of wanting to use it and learn
>why raw_input() is a better choice.[/color]

Not a propos of the O.P.'s point, but `input` is bad,
bad, bad:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> import sys
>>> d=input("Number , please ")[/color][/color][/color]
Number, please sys.setrecursio nlimit(1)[color=blue][color=green][color=darkred]
>>> d
>>> d
>>> d
>>>[/color][/color][/color]


I agree with everything the 2.3 Library Reference says
about input, except "not safe from user errors!" seems
understated.

input can be a handy tool for showing your friends
how viruses work.

Regards. Mel.

[Michele Simionato]

another candidate for deprecation (was: Why should input(prompt=&q uot;hello:&quot ;) fail?)

Peter Hansen <peter@engcorp. com> wrote in message news:<3FC23B46. 8E2BF00B@engcor p.com>...[color=blue]
> Note however that input() is a poor choice for serious work: you
> should quickly get past the point of wanting to use it and learn
> why raw_input() is a better choice.
>
> -Peter[/color]

Very true. Is "input" a candidate for deprecation in 3.0?
If not, here I give my vote to put "input" in the black list ;)


Michele

[Terry Reedy]

Re: another candidate for deprecation (was: Why should input(prompt=&q uot;hello:&quot ;) fail?)


"Michele Simionato" <mis6@pitt.ed u> wrote in message
news:2259b0e2.0 311242208.6f74e 99e@posting.goo gle.com...[color=blue]
> Very true. Is "input" a candidate for deprecation in 3.0?
> If not, here I give my vote to put "input" in the black list ;)[/color]

There have been serious (I believe) suggestions to execute

raw_input = input
del raw_input

TJR

[Ville Vainio]

Re: another candidate for deprecation (was: Why should input(prompt=&q uot;hello:&quot ;) fail?)

"Terry Reedy" <tjreedy@udel.e du> writes:
[color=blue]
> There have been serious (I believe) suggestions to execute
>
> raw_input = input
> del raw_input[/color]

So it wasn't

input = raw_input
del raw_input

?

I could understand (and support) that one...


--
Ville Vainio http://www.students.tut.fi/~vainio24

[Fredrik Lundh]

Re: Why should input(prompt=&q uot;hello:&quot ;) fail?

"djw" <donald.welch.n ospam@hp.com> wrote:
[color=blue]
> Doesn't this have more to do with the difference between C-based and Python
> based modules in the std. lib?
>
> Discussion on this topic:
> http://tinyurl.com/wcgn
>
> My spot checking indicates that you can use keyword args as shown in the
> documentation, as long as its a Python based module. C-based modules seem
> to be hit-or-miss, some support it, some don't. I actually think this could
> be an improvement to the docs - actually show the way the function is
> defined so that it is clear what (if any) keyword args are possible.[/color]

if you care the slightest about maintainability , don't use keyword arguments
unless the documentation *explicitly* says that you can or should.

and if the documentation says that you *should* use keyword arguments,
don't use positional arguments just because you think you can.

</F>

[Skip Montanaro]

Re: another candidate for deprecation (was: Why should

[color=blue][color=green]
>> Note however that input() is a poor choice for serious work: you
>> should quickly get past the point of wanting to use it and learn why
>> raw_input() is a better choice.[/color][/color]

Michele> Very true. Is "input" a candidate for deprecation in 3.0? If
Michele> not, here I give my vote to put "input" in the black list ;)

Even better, deprecate input() and rename raw_input() to input()...

Skip

[Peter Hansen]

Re: another candidate for deprecation (was: Why

Skip Montanaro wrote:[color=blue]
>[color=green][color=darkred]
> >> Note however that input() is a poor choice for serious work: you
> >> should quickly get past the point of wanting to use it and learn why
> >> raw_input() is a better choice.[/color][/color]
>
> Michele> Very true. Is "input" a candidate for deprecation in 3.0? If
> Michele> not, here I give my vote to put "input" in the black list ;)
>
> Even better, deprecate input() and rename raw_input() to input()...[/color]

If you mean do those two things at the same time, you've just deprecated the
use of "input" and then provided only a routine named "input"...

And if you mean to separate them with one release to give time for the
deprecation notice to spread around, you'll just confuse people when you
then add "input" back in, but with different functionality.

(I agree with the idea of reusing the name input() for the One True Input
Routine, but not with deprecating anything as it will just confuse the issue.)

-Peter

[Aahz]

Re: another candidate for deprecation (was: Why

In article <3FC388F2.8FB1B 8D2@engcorp.com >,
Peter Hansen <peter@engcorp. com> wrote:[color=blue]
>Skip Montanaro wrote:[color=green]
>>
>> Even better, deprecate input() and rename raw_input() to input()...[/color]
>
>If you mean do those two things at the same time, you've just
>deprecated the use of "input" and then provided only a routine named
>"input"...
>
>And if you mean to separate them with one release to give time for the
>deprecation notice to spread around, you'll just confuse people when
>you then add "input" back in, but with different functionality.
>
>(I agree with the idea of reusing the name input() for the One True
>Input Routine, but not with deprecating anything as it will just
>confuse the issue.)[/color]

Yeah, what would make more sense would be to rename input() to
eval_input() and rename raw_input() to input(), and immediately
deprecate eval_input().
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.