Phillip J. Eby wrote: > At 3:16 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote: >> Phillip J. Eby wrote: >> > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
