docstringargs: Python module for setting up argparse

[Chris Angelico]

On Tue, Apr 21, 2015 at 3:08 PM, Paul Rubin <no.email at nospam.invalid> wrote:
> Chris Angelico <rosuav at gmail.com> writes:
>> PEP 484 says that type hints don't need a decorator, but if it were
>> anything else, then yes, it'd need a second decorator. But what if one
>> of the annotation usages wants to be a dictionary? How can you elide
>> the outer dictionary and still recognize what's going on?
>
> If there's only one annotation it can take a dictionary without an outer
> one.  If there's more than one annotation then they would have to be
> labelled: I don't see what difference it makes if one of the annotation
> values is a dictionary.

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.

>> that everything is right there in the function signature... but look
>> how easy it is to introduce bugs: you're inconsistent about whether
>> the first parameter is called "name" or "user".
>
> Heh, nice catch, it's late here.  But, that would have been caught
> immediately by the type checker examining the type annotation.

Assuming you run it immediately. But it's still a problem to have that
duplication - just as it can be if you put this kind of info into a
docstring, or anything else. The less duplication, the less chance of
bugs.

>> This is exactly why annotations exist. Like decorators themselves,
>> they reduce repetition and thus bugs.
>
> Type annotations add a small amount of repetition but they do reduce
> bugs.  That's the reason for having them.

Type hints help to reduce bugs, that's why they exist. Annotations are
one way of embedding type hints (and other info) into source code. The
advantage of annotations over docstring or decorator type hints is the
reduction of repetition.

ChrisA