There could be future compatibility issues between libraries using the new
function annotation scheme: PEP 3107 -- Function Annotations
See also: http://www.python.org/dev/peps/pep-3107/
Let's assume two hypotetic libraries:
mashaller: provides JSON marshalling support
typechecker: provides runtime type checking
Let's write a simple function that uses both libraries:
from marshaller import marshall, JSON
from typechecker import check, Str
@marshall
@check
def splitter(s:Str) -> JSON:
return s.split(',')
The function get a singe string and returns JSON encoded list of it's comma
separated parts. Both libraries can be used together without problems as long
as all arguments and the return value are annotated by at most one annotator
object. However, there could be frequent use cases, when multiple annotations
for a single argument or return value is required:
@marshall
@check
def splitter(s:(JSON, Str)) -> JSON:
return s.split(',')
The above function does the same as the first one, but accepts a JSON encoded
string. This solution works only if both libraries can cooperatively handle
composite annotator objects and do not complain about unknown ones.
(Note, that the order of processing depends on the order of the decorators,
not on the order of the annotators.)
Let me suggest the following recommendation for tool developers:
If you encounter a tuple as the annotator, then iterate it and process only
the known ones while silently skipping all others. Keep all existing
annotators if you include new ones. Create a tuple if you find an existing
annotator and need to include a second one. Extend existing tuples by
replacing them with new ones including new annotator(s).
(Possibly lists or dictionaries in place of tuples? I don't think so. Ideas?)
This way all annotation based tools will be compatible and should work
seamlessly without imposing any unnecessary constraint.
Anybody with a better solution? Any comments?
Greetings, Viktor
--
http://mail.python.org/mailman/listinfo/python-list
