On Thu, Jun 19, 2003 at 09:51:01AM +0200, Martin v. Löwis wrote:
Now, I understand the reason for the change, and I agree it is a sensible change. It also is a serious incompatibility. I have no problems with serious incompatibilities as long as they are properly documented and announced.
The bind(n) manpage shipped with tcl 8.2.1 says this: Unless otherwise indicated, the replacement string is the decimal value of the given field from the current event. Some of the substitutions are only valid for certain types of events; if they are used for other types of events the value substituted is undefined. If I was being a language-lawyer, I'd sure attempt to argue that "the value substituted is undefined" means that "??" is one undefined value permissible by the spec.
... but I can't seriously believe that, because the *type* of the field is an integer, so to meet the letter of the manpage the undefined value must be some integer (or string representing an integer), not a non-integer string like "??".
Anyway, while I don't know the tcl/tk development process, I suspect that if a Python advocate was active there (for instance, compiling python against tcl/tk CVS and reporting breakage) that this might have been avoided. It's a pity that nobody has appointed themselves to this role. Even if the tk developers had still made the incompatible change in a dot-dot-release (rather than, say, substituting a plainly out-of-range integer, like -sys.maxint-1), the Python community would have heard about it before that release was out of CVS. It would be nice if there was someone up ahead to make sure the light is not an oncoming train.
I wish *I* had the time to do this but hell -- I can't get my company's product to move forward from the 8.2.1 release whose manpage I quoted, not even to a later 8.2.x release!