New submission from Frank van Dijk:

stackoverflow.com has a zillion answers recommending the use of codecs.open() 
as a unicode capable drop in replacement for open(). This probably means that 
there is still a lot of code being written that uses codecs.open(). That's bad 
thing because of codecs.open()'s lack of newline conversion. A lot of that code 
will 
- have compatibility issues when it is moved between unix and windows
- silently break text files on windows, leading to issues further downstream 
(confusing other tools, messing up revision control histories)

The problem has been fixed with io.open() in 2.x and open() in 3.x. 
Unfortunately the 2.7 unicode HOWTO still recommends the use of codecs.open(). 
The 2.7 and the 3.x documentation of codecs.open() doesn't refer the reader to 
better alternatives.

The attached patches fix that.

The only downside I see is that newly written code that uses the better 
alternatives would be incompatible with 2.5 and older. However croaking on a 
small minority of systems is better than silently disrupting workflows, causing 
platform incompatibilities, and inviting flaky workarounds.

The 2.7 patch makes the unicode HOWTO recommend io.open() instead of 
codecs.open(). Both patches change the codecs.open() documentation to refer to 
io.open() or (on 3.x) open().

Additionally I removed the "data loss" explanation from codecs.open()'s note 
about its lack of newline conversion. It is not particularly helpful 
information and it is not entirely correct (data loss could also have been 
avoided by doing newline conversion before encoding and after decoding)

----------
assignee: docs@python
components: Documentation
files: codecsopen2.patch
keywords: patch
messages: 224632
nosy: Frank.van.Dijk, docs@python
priority: normal
severity: normal
status: open
title: patch: steer people away from codecs.open
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36234/codecsopen2.patch

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22128>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to