[Python-3000] Draft pre-PEP: function annotations (original) (raw)

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