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

Josiah Carlson jcarlson at uci.edu
Fri Aug 11 18:04:54 CEST 2006

"Phillip J. Eby" <pje at telecommunity.com> wrote:

At 06:10 AM 8/11/2006 -0700, Talin <talin at acm.org> wrote: >Or to put it another way: If you create a tool, and you assume that tool >will only be used in certain specific ways, but you fail to enforce that >limitation, then your assumption will be dead wrong. The idea that there >will only be a few type annotation providers who will all nicely >cooperate with one another is just as naive as I was in the SysEx debacle. Are you saying that function annotations are a bad idea because we won't be able to pickle them?

That is not what I got out of the message at all.

If not, your entire argument seems specious. Actually, even if that is your argument, it's specious, since all that's needed to support pickling is to support pickling. All that's needed to support printing is to support printing (via str), and so on.

I think you misunderstood Talin. While it was a pain for him to work his way through implementing all of the loading/etc. protocols, I believe his point was that if we allow any and all arbitrary metadata to be placed on arguments to and from functions, then invariably there will be multiple methods of doing as much. That isn't a problem unto itself, but when there ends up being multiple metadata formats, with multiple interpretations of them, and a user decides that they want to combine the functionality of two metadata formats, they may be stuck due to incompatibilities, etc.

I think that it can be fixed by defining a standard mechanism for 'metadata chaining', one involving tuples and/or dictionaries.

Say, for example, we have the following function definition: def foo(argn:meta=dflt): ...

Since meta can take on the value of a Python expression (executed during compile-time), a tuple-based chaining would work like so:

@chainmetadatatuple(meta_fcn1, meta_fcn2)
def foo(argn:(meta1, meta2)=dflt):
    ...

And a dictionary-based chaining would work like so: @chainmetadatadict(m1=meta_fcn1, m2=meta_fcn2) def foo(argn:{'m1'=meta1, 'm2'=meta2}=dflt): ...

The reason to include the dict-based option is to allow for annotations to be optional.

This method may or may not be good. But, if we don't define a standard method for metadata to be combined from multiple protocols, etc., then we could end up with incompatabilities. However, if we do define a standard chaining mechanism, then it can be used, and presumably we shouldn't run into problems relating to incompatible annotation, etc.

More information about the Python-3000 mailing list