[Python-3000] Conventions for annotation consumers (was: Re: Draft pre-PEP: function annotations)
Jim Jewett
jimjjewett at gmail.com
Wed Aug 16 01:08:41 CEST 2006
On 8/15/06, Collin Winter <collinw at gmail.com> wrote:
> Here's another stab at my earlier idea: ...
> We're still using dicts to hold the annotations, but instead of having
> the dict keyed on the name (function.__name__) of the annotation
> consumer, the keys are arbitrary (for certain values of "arbitrary").
> To enable both in-program and static analysis, the most prominent keys
> will be specified by the PEP. In this example, "type" and "doc" are
> reserved keys; anything that needs the intended type of an annotation
> will look at the "type" key, anything that's looking for special doc
> strings will look at the "doc" key. Any other consumers are free to
> define whatever keys they want (e.g., "constrain_values", above), so
> long as they stay away from the reserved strings.
That seems to get the worst of both worlds.
Static tools will now know that something is intended to express type
information, but still won't know whether it describes typical usage,
an invariant, or an adapter that will make any argument work.
Meanwhile, two different systems can still clash on "constrain_values"
(as well as "type"), without the benefit of an actual type object (or
a name associated with an import) to disambiguate.
> 1) Static analysis tools (pychecker, optimising compilers, etc) must
> be able to use the annotations
If the ownership is by object type, then static tools can get at least
a pretty good idea by looking at the name used to construct those
types. Realistically, if
>>> from zope.mypackage import something as anno1
...
>>> def f(a:anno1("asfd"))
does not provide enough information, then nothing static ever will.
-jJ
More information about the Python-3000
mailing list