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

[zhi]

Really confused, when I use keyword style argument as following:

Traceback (most recent call last):
File "<pyshell#52>", line 1, in -toplevel-
input(prompt="hello")
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]

Really confused, when I use keyword style argument as following:

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

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

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]

Really confused, when I use keyword style argument as following:

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

 

[djw]

Really confused, when I use keyword style argument as following:

input(prompt="hello")

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

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

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

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

Really confused, when I use keyword style argument as following:

input(prompt="hello")

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

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

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

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

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

 

[Michele Simionato]

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

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

 

[Fredrik Lundh]

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.

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>

 

[Terry Reedy]

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

There have been serious (I believe) suggestions to execute

raw_input = input
del raw_input

TJR

 

[Ville Vainio]

There have been serious (I believe) suggestions to execute

raw_input = input
del raw_input

So it wasn't

input = raw_input
del raw_input

?

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

 

[Skip Montanaro]

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]

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()...

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]

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.)

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().