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

[Phillip J. Eby]

At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote:
>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 was giving him the benefit of the doubt by assuming he was bringing up a 
*new* objection that I hadn't already answered.  This "incompatibility" 
argument has already been addressed; it is trivially solved by overloaded 
functions (e.g. pickle.dump(), str(), iter(), etc.).


>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.

Not if you use overloaded functions to define the operations you're going 
to perform.  You and Talin are proposing a problem here that is not only 
hypothetical, it's non-existent.

Remember, PEAK already does this kind of openly-extensible metadata for 
attributes, using a single-dispatch overloaded function (analagous to 
pickle.dump).  If you want to show that it's really possible to create 
"incompatible" annotations, try creating some for attributes in PEAK.

But, you'll quickly find that the only "meaning" that metadata has is 
*operational*.  That is, either some behavior is influenced by the 
metadata, or no behavior is.  If no behavior is involved, then there can be 
no incompatibility.  If there is behavior, there is an operation to be 
performed, and that operation can be based on the type of the metadata.

Ergo, using an overloadable function for the operation to be performed 
allows a meaning to be defined for the specific combination of operation 
and type.  Therefore, there is no problem - every piece of metadata may be 
assigned a meaning that is relevant for each operation that needs to be 
performed.

Now, it is of course possible that two pieces of metadata may be 
contradictory, redundant, overlapping, etc.  However, this has nothing to 
do with whether the semantics of metadata are predefined.  Any 
sufficiently-useful annotation scheme will include these possibilities, and 
the operations to be performed are going to have to have some defined 
semantics for them.  This is entirely independent of whether there is more 
than one metadata framework in existence.