[Python-3000] Draft pre-PEP: function annotations

Phillip J. Eby pje at telecommunity.com
Tue Aug 15 03:33:03 CEST 2006


At 01:13 PM 8/15/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
>>It can't be a "separate program altogether", since to get at the 
>>annotations, the  program must import the module that contains them.
>
>Why? I can imagine something like a documentation
>generator or static type checker that just parses the
>source, being careful not to execute anything.

How is such a thing going to know what doc("foo") means at the time the 
code is run?  What about closures, dynamic imports, etc.?


>Also, even if it does work by importing the module,
>how is the module being imported supposed to know
>which annotation processor is going to be processing
>its annotations, and therefore what generic methods
>need to be overridden, and how to go about doing
>that -- assuming there is no standardisation of any
>sort?

Weak imports are a good solution for the case where interop is 
optional.  You do something like:

     @whenImported('some.doc.processor')
     def registerDocHandler(processor):
         @processor.someOverloadedFunction.when(SomeType)
         def handleTypeDefinedByThisModule(...):
             ...

The idea here being that the registration occurs if and only if the 
some.doc.processor module is imported during the lifetime of the 
program.  See http://cheeseshop.python.org/pypi/Importing for a package 
that contains a non-decorator version of this functionality.

Anyway, the idea here is that if you create a library with a bunch of 
annotation types in it, you use weak importing to optionally register 
handlers for whatever processors are out there that you want to 
support.  Also, other people can of course define their own third-party 
glue modules that provide this kind of support for some given combination 
of annotation types and processors.



More information about the Python-3000 mailing list