[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