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

Discussion in 'Python' started by zhi, Nov 24, 2003.

  1. zhi

    zhi Guest

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

    I am using python 2.3 for windows.
    Have anyone tried this?
    I am new to python, please help me, thanks.
     
    zhi, Nov 24, 2003
    #1
    1. Advertising

  2. zhi

    Peter Hansen Guest

    zhi wrote:
    >
    > 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
     
    Peter Hansen, Nov 24, 2003
    #2
    1. Advertising

  3. (zhi) writes:

    > 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

    --
    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)
     
    Michael Hudson, Nov 24, 2003
    #3
  4. zhi

    djw Guest

    Peter Hansen wrote:

    > zhi wrote:
    >>
    >> 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)

    >>> cmp(x=1,y=2)

    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)

    >>> calendar.leapdays(y2=2004,y1=2003)

    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
     
    djw, Nov 24, 2003
    #4
  5. zhi

    Peter Hansen Guest

    djw wrote:
    >
    > Peter Hansen wrote:
    >
    > > zhi wrote:
    > >>
    > >> 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
     
    Peter Hansen, Nov 24, 2003
    #5
  6. another candidate for deprecation (was: Why should input(prompt="hello:") fail?)

    Peter Hansen <> wrote in message news:<>...
    > 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
     
    Michele Simionato, Nov 25, 2003
    #6
  7. "djw" <> wrote:

    > 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>
     
    Fredrik Lundh, Nov 25, 2003
    #7
  8. zhi

    Terry Reedy Guest

    Re: another candidate for deprecation (was: Why should input(prompt="hello:") fail?)

    "Michele Simionato" <> wrote in message
    news:...
    > 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
     
    Terry Reedy, Nov 25, 2003
    #8
  9. zhi

    Ville Vainio Guest

    Re: another candidate for deprecation (was: Why should input(prompt="hello:") fail?)

    "Terry Reedy" <> writes:

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


    --
    Ville Vainio http://www.students.tut.fi/~vainio24
     
    Ville Vainio, Nov 25, 2003
    #9
  10. Re: another candidate for deprecation (was: Why should


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


    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
     
    Skip Montanaro, Nov 25, 2003
    #10
  11. zhi

    Peter Hansen Guest

    Re: another candidate for deprecation (was: Why

    Skip Montanaro wrote:
    >
    > >> 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.

    >
    > 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
     
    Peter Hansen, Nov 25, 2003
    #11
  12. zhi

    Aahz Guest

    Re: another candidate for deprecation (was: Why

    In article <>,
    Peter Hansen <> wrote:
    >Skip Montanaro wrote:
    >>
    >> 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.)


    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 () <*> 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.
     
    Aahz, Nov 25, 2003
    #12
    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. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,128
    Smokey Grindel
    Dec 2, 2006
  2. Roy
    Replies:
    6
    Views:
    672
    Roedy Green
    Jan 7, 2008
  3. gaurav kashyap
    Replies:
    2
    Views:
    646
    gaurav kashyap
    Oct 30, 2008
  4. gaurav kashyap
    Replies:
    3
    Views:
    712
    gaurav kashyap
    Oct 31, 2008
  5. Mel
    Replies:
    10
    Views:
    3,191
    Sailaja Appi
    Feb 13, 2009
Loading...

Share This Page