On Wed, Oct 13, 2010 at 12:10 PM, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-10-13, Jean-Michel Pichavant <jeanmic...@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-nos...@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
>
--
http://mail.python.org/mailman/listinfo/python-list
