-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Document codecs.encode and codecs.decode #62027
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The codecs module has long offered encode() and decode() convenience functions (since 2004: http://hg.python.org/cpython-fullhistory/rev/8ea2cb1ec598), but they're not documented (except through docstrings). We should fix that. From the docstrings: Encodes obj using the codec registered for encoding. encoding defaults Decodes obj using the codec registered for encoding. encoding defaults Note that the difference between the convenience functions in the codecs module and the methods on str, bytes and bytearray is that the latter have additional type checks to limit their usage to text encodings. str.encode expects a str->bytes conversion, while bytes.decode and bytearray.decode both expect the codec to produce a str object. codecs.encode and codecs.decode are both arbitrary object->object conversions, limited only by whatever the chosen codec supports. |
Note that in 2.7, these docs should have a ":versionadded: 2.4" marker, while in 3.3 and 3.4, they shouldn't have a version added marker at all. These functions should also get an entry in the 3.4 What's New, even though they're not actually new. |
So, why place them in What's New? |
To advertise them? It should be explained that they are not new, but that now they are documented and can/should be used. |
I was not aware that such things are placed in What's New. I just looked at such a document for 3.3... makes a lot of sense. |
This is only the second case I'm aware of where a particularly interesting piece of functionality didn't get mentioned in the appropriate What's New doc. For the other case, the zipfile execution support, we just added it in to the 2.6 What's New long after 2.6 had been released. To this day, most people don't know about that capability, which is why I suggest it's worth handling the current case (codecs.encode and codecs.decode) differently and noting their existence in the next What's New doc that people are likely to read :) |
codecs module and 'whats new' doc patch for 3.4 |
We should fix the docs for the earlier versions as well. |
New changeset b607ce6c9ee6 by Nick Coghlan in branch '3.3': New changeset 32f3d6721c84 by Nick Coghlan in branch 'default': |
Still need to backport this to 2.7 (Thanks for the preliminary patch Grant, but I'm afraid it didn't make it into what I ended up committing) |
Hmm, I just noticed an interesting issue here in drafting the 2.7 backport: as near as I can tell, these aren't tested, so other implementations that failed to provide them would pass the 2.7 and 3.3 test suites. |
Oops, never mind - the tests are already there (and have been since MAL's original commit prior to Python 2.4), I just fail at searching code. |
New changeset bdb30bdf60a5 by Nick Coghlan in branch '2.7': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: