Nick Coghlan wrote: > Terry Reedy wrote: >> This to be is an argument for keeping the default the current behavior, >> but not for rejecting flexibility. The computing world seems to be >> messier than we would like and worse that I realized until this week. As >> you say below, people need to better anticipate the future, and an >> errors parameter would help do that. > > It just occurred to me that this seems like a perfect situation to > address via the warning system. I disagree. > The normal warnings mechanics can then > be used to turn it into an exception if so desired, and this can be done > once per application rather than having to pass a separate argument > every time the affected APIs are called. The warning mechanism, as far as I know, because I have never dealt with it (and do not want to) is for version issues. In any case, the snippet that you clipped try: files = os.listdir(somedir, errors = strict) except OSError as e: log(<verbose error message that includes somedir and e>) files = os.listdir(somedir) specifically requires a per call parameter. > And the decoding problems don't pass silently either - they just get > emitted as a warning by default instead of causing the application to crash. Do they get automatically logged? In any case, the errors parameter has an in between option to neither ignore or raise but to replace and give *something* printable. This situation seems like an ideal situation for a parameter which gives the application program who uses Python a range of options to working with an un-ideal world. I am really flabbergasted why there is so much opposition to doing so in favor of more difficult or less functional alternatives. Terry Jan Reedy
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