# Deprecating codecs.open? **URL:** \ **Category:** Core Development\ **Created:** [April 13, 2025, 8:32am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135 "2025-04-13T08:32:25Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\ **Post date:** [April 13, 2025, 8:32am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/1 "2025-04-13T08:32:25Z")
`codecs.open` was a way to open text files that worked in Python 2, but with the introduction of `io.open`, its significance has greatly diminished. Now, difference between `codecs.open` and `TextIOWrapper` is a source of paper cuts. It seems we do not have enough resources to maintain the `codecs` module. - [list of codecs issues](https://github.com/orgs/python/projects/24/views/1) - [One of the edge we haven’t fixed for a long time](https://github.com/python/cpython/issues/62491) How do you think about deprecating `codecs.open`, `StreamReader` and `StreamWriter`? Does they have any use cases that cannot be replaced with `open` and `io.TextIOWrapper`? Since they have replacements from old days, I think 3 years deprecation in document + 3 years DeprecationWarning is enough for remove them. ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [April 13, 2025, 11:58am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/2 "2025-04-13T11:58:05Z")
[Searching the top 15k PyPI projects](https://hugovk.dev/blog/2022/how-to-search-5000-python-projects/) (downloaded today) for `codecs\.open`: - Found 1,567 matching lines in 613 projects `\bStreamReader\b`: - Found 2,959 matching lines in 247 projects `\bStreamWriter\b`: - Found 2,565 matching lines in 185 projects I can share the details if wanted, it’s too big for Discord. ---
**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\ **Post date:** [April 14, 2025, 6:47am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/3 "2025-04-14T06:47:56Z")
Most StreamReader and StreamWriter are asyncio or aiohttp. Anyway, it is difficult to remove codecs.open and StreamReader/Writer cannot be deprecated unless codecs.open deprecated. How about deprecate `codecs.open` without removal schedule? Like alias methods in TestCase, we need very long deprecation period. Maybe 10+ years. ---
**Author:** ![malemburg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/malemburg/32/50_2.png) [@malemburg](https://discuss.python.org/u/malemburg)\ **Post date:** [April 14, 2025, 8:16am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/4 "2025-04-14T08:16:32Z")
I think you are forgetting that `StreamRead/Writer` play a central part in the whole codecs sub-system, so eventually removing them would require a lot more redesign work for the sub-system to continue working (both are part of the what defines a codec in Python - see `CodecInfo`) You’d have to essentially replace the StreamReader/Writer logic which the codec sub-system uses with `io` stack classes - that is, after investigating whether this is easily possible. They look fairly similar, but their method signatures are different, `TextIOWrapper` does not separate reading and writing and the semantics are different as well. So overall, I think the idea of simply deprecating the two base classes is premature at this point. ---
**Author:** ![methane](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/methane/32/43_2.png) [@methane](https://discuss.python.org/u/methane)\ **Post date:** [April 14, 2025, 8:49am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/5 "2025-04-14T08:49:09Z")
> [@malemburg](#): > > So overall, I think the idea of simply deprecating the two base classes is premature at this point. Now I am proposing deprecating only `codecs.open`. I updated the thread title. ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [April 14, 2025, 10:01am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/6 "2025-04-14T10:01:48Z")
In 2010, I wrote [PEP 400 – Deprecate codecs.StreamReader and codecs.StreamWriter](https://peps.python.org/pep-0400/). See related discussions: - [Deprecate codecs.open() · Issue #53042 · python/cpython · GitHub](https://github.com/python/cpython/issues/53042) - [[Python-Dev] Deprecate codecs.open() and StreamWriter/StreamReader](https://mail.python.org/pipermail/python-dev/2011-May/111591.html) ---
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [April 14, 2025, 10:37am UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/7 "2025-04-14T10:37:57Z")
> [@malemburg](#): > > I think you are forgetting that `StreamRead/Writer` play a central part in the whole codecs sub-system, so eventually removing them would require a lot more redesign work for the sub-system to continue working (both are part of the what defines a codec in Python - see `CodecInfo`) `CodecInfo.streamreader` and `CodecInfo.streamwriter` are only used by `codecs.open()`. Would you mind to elaborate what do you mean by “play a central part in the whole codecs sub-system”? It’s possible to emit a `DeprecationWarning` in `StreamReader` and `StreamWriter` constructor without breaking Python. It remains possible to define sub-classes (without emitting `DeprecationWarning`) which is needed to define codecs such as UTF-8 (`Lib/encodings/utf_8.py`): ```py class StreamWriter(codecs.StreamWriter): encode = codecs.utf_8_encode class StreamReader(codecs.StreamReader): decode = codecs.utf_8_decode ``` ---
**Author:** ![malemburg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/malemburg/32/50_2.png) [@malemburg](https://discuss.python.org/u/malemburg)\ **Post date:** [April 14, 2025, 6:58pm UTC](https://discuss.python.org/t/deprecating-codecs-open/88135/8 "2025-04-14T18:58:41Z")
> [@vstinner](#): > > `CodecInfo.streamreader` and `CodecInfo.streamwriter` are only used by `codecs.open()`. Would you mind to elaborate what do you mean by “play a central part in the whole codecs sub-system”? Every single codec in Python exposes subclasses of these two base classes via the `CodecInfo` returned by the codec search function. [PEP 100](https://peps.python.org/pep-0100/) has the details. > [@methane](#): > > Now I am proposing deprecating only `codecs.open`. I updated the thread title. +1 on soft deprecating `codecs.open()`, without actually removing the function for a longer while. The standard `open()` is the better choice these days. Still, the function is still in wide spread use, so it’ll take a longer while to convince people to reconsider their choice. It is still needed by projects wanting to maintain Python 2 compatibility. Note that deprecating the function will not allow deprecating `StreamReader/Writer` as a result, unless there’s a working migration path forward to e.g. use new base classes around the `io` stack for the codecs. These could be added as additional fields in `CodecInfo` and have codecs slowly migrate over with a longer deprecation period