为什么Python 3.x移除了作为编码方式的ROT-13？

Great question! You’ve hit the nail on the head with your guess—ROT-13 isn’t a real text encoding, and Python 3’s stricter API design is the core reason for this change. Let’s break it down:

Python 2’s Loose String Handling #

In Python 2.7, the line between "text encoding" and "character transformations" was pretty blurry. The str.encode() method allowed non-standard "codecs" like ROT-13 because the language didn’t strictly distinguish between text strings and byte data. That’s why you could run this with no issues:

>>> 'abcdefghijklmnopqrstuvwxyz'.encode('rot-13')
'nopqrstuvwxyzabcdefghijklm'

Even the Easter egg code for The Zen of Python in the CPython repo used this behavior to hide its text behind ROT-13.

Python 3’s Strict Separation of Text and Bytes #

Python 3 completely overhauled string handling by separating str (human-readable text) and bytes (raw binary data). The str.encode() method was redefined to only handle true character encodings—processes that convert text into bytes (like UTF-8, ASCII, or Latin-1).

ROT-13 doesn’t fit this definition at all: it’s a simple character substitution cipher that transforms text into other text, not bytes. To keep APIs clear and avoid confusion, Python 3 moved ROT-13 (and similar non-encoding transformations) to the codecs module, which is built for general-purpose text transformations:

>>> import codecs
>>> codecs.encode('abcdefghijklmnopqrstuvwxyz', 'rot-13')
'nopqrstuvwxyzabcdefghijklm'

The Core Design Intent #

This change was intentional to make code more explicit. When you see str.encode() in Python 3, you immediately know the goal is to convert text to bytes. When you see codecs.encode(), you know it’s handling a text-to-text transformation or a non-standard codec. It eliminates ambiguity and aligns Python’s API with the actual purpose of each tool.

内容的提问来源于stack exchange，提问作者coldspeed95