[Python-Dev] Python-3.0, unicode, and os.environ

[Nick Coghlan]

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(<verbose error message that includes somedir and e>)
>   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
---------------------------------------------------------------