On Tue, Apr 21, 2015 at 3:08 PM, Paul Rubin <no.email@nospam.invalid> wrote: > Chris Angelico <ros...@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 -- https://mail.python.org/mailman/listinfo/python-list
