I mostly like this; the main issue I see is that as long as we're
recommending best practices, we should recommend using tell-don't-ask (via
duck typing protocols, adaptation, or overloaded functions) so that their
libraries can be enhanced and extended by other developers.
Would you mind suggesting text for the PEP as an addendum to what I proposed? And an example of both bad and good practice?
>"In Python 3000, semantics will be attached to the following types:
>basestring and its subtypes are to be used for documentation (though they
>are not necessarily the exclusive source of documentation about the type).
>List and its subtypes are to be used for attaching multiple independent
>annotations."
I'm not sure why we would use strings for documentation, but I'm not
opposed since it eliminates the question of multiple interpretations for
strings.
I don't understand your point. Is there a better use for strings? Or a better type to associate with documentation? Or you just don't see a need for inline parameter documentation? The PEP itself used string docstrings as an example.
>(does chaining make sense in this context?)
I don't know if I know what you mean by "chaining". Good use of
tell-don't-ask means that any interpretation of annotations nested in other
annotations would be defined by the enclosing annotation (or in an overload
for it).
Yes, it's clear what nesting means. I'm not asking about nesting.
The question was whether there should be any relationship implied by the fact that an annotation appears to the left or right of another annotation in a list of annotations.
def a(b: [doc('x'), type('y')]): pass
Is there any sense in which the function 'x' should be passed context information that would help it wrap or communicate with 'y'?
The most likely answer is "no" but function decorators do chain so I just wanted to raise the issue in case anyone wanted to make the case that parameter and return code annotations should as well.
Paul Prescod
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
