Guido van Rossum wrote: > >... > > Disagree. Warnings are there mostly for the Python system to warn the > Python programmer. The most heavy use will come from the standard > library, not from user code. Most Python code is part of some library or another. It may not be the standard library but its still a library. Perl and Java both make warnings (especially about deprecation) very easy *for user code*. > > * it should be possible to strip warnings as an optimization step. That > > may require interpreter and syntax support. > > I don't see the point of this. I think this comes from our different > views on who should issue warnings. Everyone who creates a reusable library will want to issue warnings. That is to say, most serious Python programmers. Anyhow, let's presume that it is only the standard library that issues warnings (for arguments sake). What if I have a speed-critical module that triggers warnings in an inner loop. Turning off the warning doesn't turn off the overhead of the warning infrastructure. I should be able to turn off the overhead easily -- ideally from the Python command line. And I still feel that part of that "overhead" is in the code that tests to determine whether to issue the warnings. There should be a way to turn off that overhead also. Paul
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