docstringargs: Python module for setting up argparse

Chris Angelico rosuav at gmail.com
Tue Apr 21 08:03:40 CEST 2015


On Tue, Apr 21, 2015 at 3:54 PM, Paul Rubin <no.email at nospam.invalid> wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>> Other decorators have to be able to recognize whether there's an outer
>> dictionary or not. That means they have to dig into the annotating
>> object to inquire as to whether or not their thing is there.
>
> I'm imagining the annotation consumers themselves being wrapped by
> something that handles that automatically:
>
> @annotation
> def cmdline(**args): ...
>
> This turns cmdline into something that takes the function object, peels
> off the cmdline annotations, and gives them to the function in the def.
>
> There is still the issue of figuring out when there is just one
> consumer, or more generally, identifying the outermost one.  But it
> should be possible to come up with something.  Is there a metaclass for
> functions that can notice when a def or decorator is run, or anything
> like that?

Ow, this is getting extremely complicated. And you still haven't
actually answered the fundamental problem, which is: When will you
need this? When will you actually want to put two different
annotations onto the same function's parameters?

A similar consideration applies to a class's metaclass. You can do a
lot of different things with metaclasses, but how often do you really
need to merge two of them? Almost never. (Not absolutely never; a
proposal came up recently for dealing with one edge case around
metaclasses. But it's still pretty rare.)

>>> would have been caught immediately by the type checker
>> Assuming you run it immediately.
>
> I thought the idea of type checking is that it's run at compile time.
> Maybe not as soon as the decorator is seen, since type info has to
> propagate through the whole program before checking can finish, but it
> gets caught when the checker runs.

The language isn't going to get any type checking. I suppose you could
mandate that all source control check-ins pass a type scan, but that's
no different from any other checks (eg "make sure the unit tests pass
before you push changes" or "make sure the buildbots are all green
before releasing to the client"). There's a disconnect between the
keying-in of code and the check being run, which means the bug can sit
there for anywhere from a few seconds to a few months (or worse). But
if there's no duplication of names, there can't possibly be an error
of naming.

ChrisA



More information about the Python-list mailing list