Victor Stinner <victor.stinner <at> haypocalc.com> writes: > I opened an issue for this idea. Brett and Marc-Andree Lemburg don't > want to deprecate codecs.open() & friends because they want to be able > to write code working on Python 2 and on Python 3 without any change. I > don't think it's realistic: nontrivial programs require at least the six > module, and most likely the 2to3 program. The six module can have its > "codecs.open" function if codecs.open is removed from Python 3.4. What's "non-trivial"? Both pip and virtualenv (widely used programs) were ported to Python 3 using a single codebase for 2.x and 3.x, because it seemed to involve the least ongoing maintenance burden. Though these particular programs don't use codecs.open, I don't see much value in making it harder to write programs which can run under both 2.x and 3.x; that's not going to speed adoption of 3.x. I find 2to3 very useful indeed for showing where changes may need to be made for 2.x/3.x portability, but do not use it as an automatic conversion tool. The six module is very useful, too, but some projects won't necessarily want to add it as an additional dependency, and reimplement just the parts they need from that bag of tricks. So I would also want to keep codecs.open() and friends, at least for now - though it makes seems to make sense to implement them as wrappers (as Nick suggested). Regards, Vinay Sajip
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