On Thu, Jun 19, 2003 at 09:51:01AM +0200, Martin v. L=F6wis 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=20
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!
Jeff
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4