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

[Talin]

Phillip J. Eby wrote:
> At 3:16 PM 8/12/2006 -0700, Talin <talin at acm.org> wrote:
>> Phillip J. Eby 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?
>>
>> Huh? What does pickling have to do with anything I said?
> 
> I'll happily answer that question as soon as you explain what *function 
> annotations* have to do with anything you said.  Bonus points if you can 
> explain what MIDI has to do with overloaded functions.  :)

All right. I realize that not everyone made the connection between my 
parable and the current debate, and I need to spell it out more explicitly.

The parable is essentially about standards-writers who fail to do their 
job by underspecifying certain aspects of the standard, and leave the 
solution to individual implementers of the standard; And its also how 
the implementers who try to fill in the missing pieces of the standard 
do so in a way that is unique and incompatible with what every other 
implementer is doing.

The story also has to do with people who assume things about the 
behavior of other software developers - specifically, my assumption that 
other people, working in isolation from one another, would come up with 
the same or similar solutions to a given problem, vs. Colin's assumption 
that other creators of annotation interpreters would coordinate their 
efforts in a sensible way.

What the annotation PEP and the SysEx have in common is that they are 
both dealing with an open-ended specification - one which allows any 
provider to extend the protocol in any way they wish, without any 
knowledge or coordination from any other provider. Both specs describe a 
'container' for information, but deliberately avoid saying what's in the 
container. Both specs fail to provide any means for an external entity 
to discover the meaning of what the objects in the container are - 
instead, external entities must have a priori knowledge of the contained 
data.

My criticism of Colin's PEP was that it hand-waved over some fairly 
major problems, and the logic behind the hand-wave was that, well, 
developers won't do that - there's only going to be a small number of 
such developers, and they will all deal with each other. I wanted to 
illustrate how disastrous such an assumption could be.

Another lesson of the story has to do with the failure of the MMA 
committee to specify any guidelines or hints as to how their open-ended 
protocol should be used. If the MMA had simply put a paragraph in the 
original standard saying "You are free to create any protocol format you 
want, but here's an example of how a bulk dump protocol might work" 
(followed by a description of such), then what would have happened is 
that most of the instrument makers would simply have used the example as 
a starting point. This would have saved millions of man-hours of 
confusion and chaos over the last 20 years. Dozens of companies created 
Universal Librarian products, and all of them had to deal with the 
astounding diversity of protocols, which could have been avoided by one 
little non-binding paragraph in the standard.

In other words, I criticize both the MMA's spec and Colin's for the sin 
of underspecification - that is, allowing critical decisions that 
*should* have been made by the standard writer to instead be made by the 
standard implementers, with the result that each implementer comes up 
with their own unique solution to a problem which should have been 
solved in the original standard doc.

-- Talin