Py3K: Ensuring future compatibility between function annotation based tools

Ferenczi Viktor python at cx.hu
Tue Sep 4 16:09:56 EDT 2007


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



More information about the Python-list mailing list