[Python-3000] Draft pre-PEP: function annotations
talin at acm.org
Sat Aug 12 04:17:37 CEST 2006
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
>> >> will only be used in certain specific ways, but you fail to enforce
>> >> limitation, then your assumption will be dead wrong. The idea that
>> >> 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
>> > 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
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.
More information about the Python-3000