method (a, b = '', *c, **d): gets a syntax error?

Discussion in 'Python' started by Andreas Neudecker, Aug 29, 2003.

  1. Hello.

    I am relatively new to Python and I have a strange problem with some
    code. In a class the __call__ method gets parameters like this:


    class WhatsUp:
    __call__ (
    self,
    var1,
    var2 = '',
    *moreVars,
    **moreNamedVars,
    ):
    pass


    I always get an error for the **moreNamedVars, line where the '^' points
    at the comma at the end (or, if I remove the comma, it points at the
    colon). I also tried commenting-out the other variables passed to the
    method. Same result.
    I assumed the order of variables and variable lists of variables had to
    be like this? What is wrong?


    Kind regards



    Andreas
     
    Andreas Neudecker, Aug 29, 2003
    #1
    1. Advertising

  2. Andreas Neudecker <> writes:

    > Hello.
    >
    > I am relatively new to Python and I have a strange problem with some
    > code. In a class the __call__ method gets parameters like this:
    >
    >
    > class WhatsUp:
    > __call__ (
    > self,
    > var1,
    > var2 = '',
    > *moreVars,
    > **moreNamedVars,
    > ):
    > pass
    >
    >
    > I always get an error for the **moreNamedVars, line where the '^'
    > points at the comma at the end (or, if I remove the comma, it points
    > at the colon). I also tried commenting-out the other variables passed
    > to the method. Same result.
    > I assumed the order of variables and variable lists of variables had
    > to be like this? What is wrong?


    Missing a def?

    Cheers,
    mwh

    --
    Any form of evilness that can be detected without *too* much effort
    is worth it... I have no idea what kind of evil we're looking for
    here or how to detect is, so I can't answer yes or no.
    -- Guido Van Rossum, python-dev
     
    Michael Hudson, Aug 29, 2003
    #2
    1. Advertising

  3. Andreas Neudecker wrote:

    > Hello.
    >
    > I am relatively new to Python and I have a strange problem with some
    > code. In a class the __call__ method gets parameters like this:
    >
    >
    > class WhatsUp:
    > __call__ (


    You're missing the keyword 'def' here, right before the method name.


    Alex
     
    Alex Martelli, Aug 29, 2003
    #3
  4. Andreas Neudecker

    Terry Reedy Guest

    "Andreas Neudecker" <> wrote in message
    news:...
    > class WhatsUp:
    > __call__ (
    > self,
    > var1,
    > var2 = '',
    > *moreVars,
    > **moreNamedVars,
    > ):
    > pass
    >
    >
    > I always get an error for the **moreNamedVars, line where the '^'

    points
    > at the comma at the end (or, if I remove the comma, it points at the
    > colon). ...What is wrong?


    Generaly, when reporting 'I got an error', you should copy the actual
    error message. In this case, I presume you got 'SyntaxError: invalid
    syntax' for each of your two syntax errors.

    1. When you make a function call and use **whatever, it must be the
    last item in the argument list, just as in a function definition. A
    following comma is not allowed for either defs or calls. So when you
    add 'def' to correct your actual error, you also need to omit the
    comma.

    2. The colon suffix is required for defs but forbidden for calls.
    With the comma present, the parser never got far enough to this.
    Unlike most batch compilers, the CPython parser quits at the first
    error it sees. So when you correct one error and resubmit, you may
    expose another further in your code.

    Welcom to Python. Enjoy.

    Terry J. Reedy
     
    Terry Reedy, Aug 29, 2003
    #4
  5. Hi.

    Terry Reedy wrote:

    > Generaly, when reporting 'I got an error', you should copy the actual
    > error message.


    Will do from now. Thanks.

    > In this case, I presume you got 'SyntaxError: invalid
    > syntax' for each of your two syntax errors.


    Exactly. Got one. As Michael Peuser states, the comma behind the last
    parameter is fine. I am doing this all the time when the list is long
    and I write it one parameter per line, because it makes swapping order
    or adding another parameter less error-prone (how often have you
    forgotten to add the comma to the previous parameter when adding a new
    'last one').

    > 1. When you make a function call and use **whatever, it must be the
    > last item in the argument list, just as in a function definition.


    I knew that. That was what puzzled me. And the pointer of the error
    message pointed to the comma. So I simply overlooked that I had
    forgotten the 'def' - what a dumb bug!

    > Welcom to Python. Enjoy.


    I do. Used to do some C long, long ago. Python is so much more
    comfortable ...

    Regards


    Andreas
     
    Andreas Neudecker, Aug 29, 2003
    #5
  6. Sorry, have to correct myself on the comma topic:


    class WhatsUp:
    # No comma at the end of the list. This works fine.
    def method1 (
    self,
    var1,
    var2 = '',
    *more,
    **moreNamed
    ):
    print "This works fine."

    # This also works fine, even with the comma at the end.
    def method2 (
    self,
    var1,
    var2 = '',
    var3 = '', # <- THIS COMMA IS FINE.
    ):
    print "This works fine."

    # This will raise a Syntax error because of the comma.
    def method3 (
    self,
    var1,
    var2 = '',
    *more,
    **moreNamed, # <- THIS COMMA IS NOT ALLOWED.
    ):
    print "The comma at the end of the parameter list will \
    raise a syntax error."


    So to me it looks like it makes a difference whether the list contains a
    variable parameter list or not. I use the version as in method2 often
    for reasons stated in my previous posting.

    Still it puzzles me that in one case it is okay in the other one not.
    Seems unlogical to me. Can anyone enlighten me to why this is so?

    Thanks to all of you who bothered to point me to my stupid error of
    forgetting the 'def' and discussing with me the comma problem.


    Kind regards


    Andreas
     
    Andreas Neudecker, Aug 29, 2003
    #6
  7. Andreas Neudecker

    Terry Reedy Guest

    "Michael Peuser" <> wrote in message
    news:bio39s$2ai$03$-online.com...
    >
    > "Terry Reedy" <> schrieb im Newsbeitrag
    > news:...
    >
    > [...}
    > >
    > > 1. When you make a function call and use **whatever, it must be

    the
    > > last item in the argument list, just as in a function definition.

    A
    > > following comma is not allowed for either defs or calls.

    >
    > This in fact is not true. Funnily you can add *one* comma at the end

    of any
    > list-like construct.


    For 2.2.1 and whatever version Andreas is running, **whatever is an
    exception and CANNOT be followed by a comma in either def or call,
    just as I said. I tested before writing. (Did you? Can you test
    below on 2.3?)

    >>> def f(**d):

    .... for i,v in d.items(): print i, v
    ....
    >>> b={'one':1, 'two':2}
    >>> f(**b)

    two 2
    one 1
    >>> f(**b,)

    File "<stdin>", line 1
    f(**b,)
    ^
    SyntaxError: invalid syntax

    >>> def f2(**d,): pass

    File "<stdin>", line 1
    def f2(**d,): pass
    ^
    SyntaxError: invalid syntax

    # On the original fixed-pitch font screen, both arrows point at
    offending comma.

    Can someone verify this for 2.3? If so, there is a bug in either doc
    or interpreter.

    Terry J. Reedy
     
    Terry Reedy, Aug 29, 2003
    #7
  8. Andreas Neudecker

    Gerrit Holl Guest

    Terry Reedy wrote:
    > >>> def f2(**d,): pass

    > File "<stdin>", line 1
    > def f2(**d,): pass
    > ^
    > SyntaxError: invalid syntax
    >
    > # On the original fixed-pitch font screen, both arrows point at
    > offending comma.
    >
    > Can someone verify this for 2.3? If so, there is a bug in either doc
    > or interpreter.


    Python 2.3 does the same.

    Python 2.3 (#1, Aug 5 2003, 14:13:25)
    [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    0 >>> zip(**(),)
    File "<stdin>", line 1
    zip(**(),)
    ^
    SyntaxError: invalid syntax
    1 >>> def foo(**a,): pass
    File "<stdin>", line 1
    def foo(**a,): pass
    ^
    SyntaxError: invalid syntax

    yours,
    Gerrit.

    --
    216. If the patient be a freed man, he receives five shekels.
    -- 1780 BC, Hammurabi, Code of Law
    --
    Asperger Syndroom - een persoonlijke benadering:
    http://people.nl.linux.org/~gerrit/
    Het zijn tijden om je zelf met politiek te bemoeien:
    http://www.sp.nl/
     
    Gerrit Holl, Sep 1, 2003
    #8
  9. Andreas Neudecker <> writes:

    [comma inconsistencies]

    > Still it puzzles me that in one case it is okay in the other one
    > not. Seems unlogical to me. Can anyone enlighten me to why this is so?


    Because that's what the grammar says. The chances of this being
    deliberate are, I would hazard, pretty tiny.

    > Thanks to all of you who bothered to point me to my stupid error of
    > forgetting the 'def' and discussing with me the comma problem.


    If it's any consolation, it took quite a bit of staring at it before I
    noticed the flaw...

    Cheers,
    mwh

    --
    I located the link but haven't bothered to re-read the article,
    preferring to post nonsense to usenet before checking my facts.
    -- Ben Wolfson, comp.lang.python
     
    Michael Hudson, Sep 1, 2003
    #9
  10. >>>>> Andreas Neudecker <> (AN) wrote:

    AN> Still it puzzles me that in one case it is okay in the other one not. Seems
    AN> unlogical to me. Can anyone enlighten me to why this is so?

    It is quite logical. The idea behind the optional comma after the last
    parameter is such that it would be easy to change your function to include
    additional parameters. When you put each parameter on a separate line (as
    you did in your examples) , you just have to add a single line with the new
    parameter and it doesn't matter whether the new parameter comes in as the
    last one or at any other place. If you leave out the final comma, and the
    new parameter is the last one, you would have to add the comma to the
    previous line, which can easily be forgotten.

    However, when you have **kwargs it must be last, so there is no need to
    put an additional comma. In fact it would be confusing as it would suggest
    that you can add additional parameters after it.
    --
    Piet van Oostrum <>
    URL: http://www.cs.uu.nl/~piet [PGP]
    Private email:
     
    Piet van Oostrum, Sep 1, 2003
    #10
  11. Andreas Neudecker

    Terry Reedy Guest


    >(Gerrit Holl) Python 2.3 does the same.
    >
    > Python 2.3 (#1, Aug 5 2003, 14:13:25)
    > [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
    > Type "help", "copyright", "credits" or "license" for more

    information.
    > 0 >>> zip(**(),)
    > File "<stdin>", line 1
    > zip(**(),)
    > ^
    > SyntaxError: invalid syntax
    > 1 >>> def foo(**a,): pass
    > File "<stdin>", line 1
    > def foo(**a,): pass
    > ^
    > SyntaxError: invalid syntax


    Thank you for the verification. I have submitted doc bug report SF
    798652

    >(Michael Hudson): Because that's what the grammar says


    After the grammer in 5.3.4 follows :"A trailing comma may be present
    after an argument list but does not affect the semantics. " I
    suggested instead "If an argument list does *not* end with *expr or
    **expr, a trailing comma may be added without affecting the
    semantics."

    I also suggested a change in 7.5 Function definitions to the
    production for parameter_list.

    >(Piet von Oostrum) [Explanation of why '**dic,)' should be error]


    I agree, which is why I filed as doc bug. Note

    >>> def fl(*lis,): pass

    File "<stdin>", line 1
    def fl(*lis,): pass
    ^ # points at ')'
    SyntaxError: invalid syntax

    The error is detected as ')' instead of ',' because **dic could have
    followed, but didn't.

    Terry J. Reedy
     
    Terry Reedy, Sep 1, 2003
    #11
  12. "Terry Reedy" <> writes:

    > >(Michael Hudson): Because that's what the grammar says

    >
    > After the grammer in 5.3.4 follows :"A trailing comma may be present
    > after an argument list but does not affect the semantics. " I
    > suggested instead "If an argument list does *not* end with *expr or
    > **expr, a trailing comma may be added without affecting the
    > semantics."


    Perhaps I should have said Grammar, as in the Grammar/Grammar file in
    the source distribution.

    FWIW, *I'd* rather see *that* tweaked so the documentation became
    correct. But really, there are more important fish to fry (and
    metaphors to mix :).

    Cheers,
    mwh

    --
    Gevalia is undrinkable low-octane see-through only slightly
    roasted bilge water. Compared to .us coffee it is quite
    drinkable. -- Måns Nilsson, asr
     
    Michael Hudson, Sep 1, 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. Stefan Mueller
    Replies:
    5
    Views:
    550
    Steven Saunderson
    Jul 10, 2006
  2. John Joyce

    gets gets

    John Joyce, Mar 26, 2007, in forum: Ruby
    Replies:
    2
    Views:
    380
    John Joyce
    Mar 26, 2007
  3. John Joyce

    Return of gets gets

    John Joyce, Apr 23, 2007, in forum: Ruby
    Replies:
    0
    Views:
    215
    John Joyce
    Apr 23, 2007
  4. Mark Richards
    Replies:
    3
    Views:
    348
    Tad McClellan
    Nov 18, 2007
  5. libsfan01
    Replies:
    5
    Views:
    273
    Jeff North
    Dec 20, 2006
Loading...

Share This Page