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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
