John Nagle <[EMAIL PROTECTED]> wrote: ... > I'd have to consider that a bug. > > Some very early FORTRAN compilers allowed you to redefine > integer constants: > > > CALL SET(25,99) > WRITE (6,100) 25 > 100 FORMAT(I6) > > SUBROUTINE SET(IVAR, INEWVAL) > IVAR = INEWVAL > > would print > > 99 > > It was generally agreed by 1970 or so that this was a bad idea, > and was taken out of the language.
It was still perfectly legal in the Fortran 1977 standard for a compiler to cause this effect, because the Fortran source you quote has *undefined behavior* -- the compiler doesn't have to diagnose this error and can cause any effects as a consequence. The point of Fortran is to let the compiler generate the fastest code it can, NOT to "tenderly hold your hand" lest scary bugs disturb your blessed and dreamy innocence. If this has changed in the Fortran 1990 standard or later, then I can only say I'm happy I stopped using Fortran heavily before such standards became widespread in commonly available compilers -- by the late '90s, when I was still using _some_ Fortran, it was Fortran '77, as that was the version that was widely available and well optimized. Python is not particularly focused on coddling the programmer lest he or she (horrors!) make a mistake, either; rather, it embodies well 4 of the 5 principles that make up the "Spirit of C" according to the Preface to C's ISO Standard -- "trust the programmer", "don't stop the programmer from doing what needs to be done", "keep the language small and simple" (the 4th one, "offer only one way to perform an operation", is not germane here). Making the language more complicated (e.g., with more reserved words) because you _don't_ trust the programmer and badly wants to stop him/her from doing something is not well consistent with these principles. Maybe somebody assigning a value to True or False is a common error, but much of my livelihood over the last 10 years has been about mentoring/coaching programmers in Python, and that's one error I have *NEVER* observed, so I'd need a lot of empirical evidence to convince me it's worth adding two more reserved words to Python's reasonably short list (I feel much the same way about None, by the way). pychecker, pylint, and friends, are a much better way to detect and warn about all sort of anomalies of this kind. Alex -- http://mail.python.org/mailman/listinfo/python-list
