[Python-Dev] Python-3.0, unicode, and os.environ (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Dec 8 22:03:56 CET 2008

Terry Reedy wrote:

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.

No, it's just DeprecationWarning in particular that is specific to versioning issues. That's obviously the one that comes up most often for core development, but there are other warnings as well (e.g. the off-by-default ImportWarning when potential packages are skipped because init.py is missing).

For this particular case, I would suggest adding something like EnvironmentWarning (to parallel the EnvironmentError that is the common parent of OSError and IOError).

In any case, the snippet that you clipped

try: files = os.listdir(somedir, errors = strict) except OSError as e: log() files = os.listdir(somedir) specifically requires a per call parameter.

True, but the decision to have "errors=warn" as the default behaviour is independent of the decision of whether or not to allow the behaviour to be changed on a case-by-case basis. There is nothing stopping us from doing both.

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?

By default warnings are written to sys.stderr. Whether that gets logged or not will depend on the nature of the application

There are also mechanisms in warnings that allow an application to override the handling of warnings (and for 2.7/3.1, there are mechanisms in logging to make it easy to hook the warning system and the logging system together, so that warnings are 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.

That's true, and why I would actually support doing both. Adding the warning is a more pressing need though, since it is what will prevent the errors from passing silently in the default case.

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.

A warning will stop the failure from passing silently in the default case - that's solving a different problem to the one that the error handling argument will solve. I do agree that being able to override the handling on a per-call basis could be a useful feature.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list