> You could also put asserts (and expressions which assert the presence of
> certain attributes) in function bodies.
Nice idea—that seems to give more flexibility, but (probably) makes it harder
to implement.
I would love to write:
assert hasattr(file_like, 'read') and hasattr(file_like, 'write')
Or maybe:
assert file_like.read and file_like.write
On the other hand, documenting type information in docstrings is also nice.
—Vladimir
08.11.2013, 11:02, "Florian Weimer" <fwei...@redhat.com>:
> On 11/07/2013 01:53 PM, Andrey Vlasovskikh wrote:
>
>>> You should take a look at NumPy docstring conventions which are fully
>>> supported by Sphinx, and are actually human-readable.
>> There are two questions here:
>>
>> 1. Where to put type information?
>>
>> * Docstrings
>> * ReStructured Text
>> (http://sphinx-doc.org/domains.html#the-python-domain)
>> * Epydoc
>> * NumPy
>> * Expressions
>> * Python 3 function annotations
>> * Decorators
>
> You could also put asserts (and expressions which assert the presence of
> certain attributes) in function bodies. Existing analysis tools should
> already process those and would only need to implement different error
> reporting in case a mismatch is detected (because the error is strictly
> with the caller, not in the skeleton module).
>
> --
> Florian Weimer / Red Hat Product Security Team
_______________________________________________
code-quality mailing list
code-quality@python.org
https://mail.python.org/mailman/listinfo/code-quality
