My first Python program

Chris Kaynor ckaynor at zindagigames.com
Wed Oct 13 21:25:12 CEST 2010


On Wed, Oct 13, 2010 at 12:10 PM, Seebs <usenet-nospam at seebs.net> wrote:

> On 2010-10-13, Jean-Michel Pichavant <jeanmichel at sequans.com> wrote:
> > If you wonder about some defects reported by such linters, you can then
> > ask in this list why something is not that good, because it may not be
> > always obvious.
>
> > 'pylint' is one them, pretty effective.
>
> Okay, several questions about stuff pylint found.
>
> 1.  If I have a message that I wish to print, it is quite possible
> that message + indentation exceeds 80 lines.  What's the idiomatic way
> to solve this?  Do I just break the string up into parts, or do I just
> accept that some lines are over 80 characters, or what?
> 2.  It warns about **kw, both because the name is short and because of
> the "** magic".  I was previously advised that the name "kw" is canonical
> for that usage, in which case, why am I getting linted at?
> 3.  More generally, the usage of **kw is probably not really right, but I'm
> not sure what to do.
>
> The issue here is as follows:
>
> In C, some functions have an optional argument with the curious trait that,
> if present, it is always of the same type.  e.g., open(2).  In my wrappers,
> I indicate this by declaring it as something like "...{mode_t mode}".  The
> intent is that in a declaration, this will turn into:
>        foo(blah blah blah, ... /* mode_t mode */)
> so there's an indication of why there's a "..." there.
> But C comments don't nest.  And there's a couple of points where I want to
> put the declaration in a comment.  So in those cases, I need to do
> something
> other than /*...*/:
>        /* foo(blah blah blah, ... mode_t mode) */
>
> The problem:  The determination of whether I wish to do this is at the
> level
> of the "represent this function in the following way" (Function.comment()),
> but the implementation is two layers down.  So right now, I am passing
> down 'comment = True' from the top level through, and I'm doing it using
> a **kw keyword argument.
>
> The rationale is that I could just use
>        def decl(comment = False):
>                ...
> but then the invocation:
>        func.decl(True)
> would be utterly opaque.  I want to name the thing I'm passing or otherwise
> indicate what it is.
>
> It could be that I am Doing This Wrong.  Is there a good idiom for labeling
> optional arguments, and passing them on (if they exist)?
>

You can always name the arguments (the following work in 2.5 and 2.6,
barring typos - the code is untested):

def func1(arg1, arg2):
    print arg1, arg2

> func1(arg2=1, arg1=2)
2 1
> func1(2, arg2=1)
2 1

def func2(arg1, arg2, optionalArg=3):
    print arg1, arg2, optionalArg

> func2(1, 2)
1 2 3
> func2(1, 2, optionalArg=4)
1 2 4
> func2(1, 2, 4)
1 2 4
> func2(arg2=1, arg1=2, optionalArg=4)
2 1 4

You can also mix and match:

def func1(arg1, arg2, arg3):
    print arg1, arg2, arg3

> func1(1, arg3=2, arg2=3)
1 3 2



> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach /
> usenet-nospam at seebs.net
> http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
> http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> I am not speaking for my employer, although they do rent some of my
> opinions.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20101013/91f464a9/attachment.html>


More information about the Python-list mailing list