>> People who want to use the feature would have to know that it is only >> present if you turn it on. It's like saying "you can use hexadecimal >> integer literals, but you have to turn them on". This wouldn't work: >> people try to use them, find out that it won't work, and assume >> that it's not supported. > > Are we going to stop offering informational error messages to people? > Because an informational error message could go a long way towards > helping people to understand what is going on.
I don't think there is precedence in Python for such an informational error message. It is not pythonic to give an error in the case "I know what you want, and I could easily do it, but I don't feel like doing it, read these ten pages of text to learn more about the problem". The most similar case is the future import statement, where we in fact report an error even though it's typically clear what the desired meaning of the program is. However, this statement is only meant as a transitional measure, with a view of eventually changing the error into making the future behavior the default. I understand that you want that to be a permanent error, and this I object to. People should not have to read long system configuration pages just to run the program that they intuitively wrote correctly right from the start. If you think there are cases in which the user should be warned about potential problems and risks, then the warning machinery would be more appropriate. Of course, it would be important to not produce too many false positives for such a warning. Regards, Martin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
