homepage

Quoting Victor Stinner from msg106669:
"""
It's maybe possible for write some 2to3 fixers for the following examples:
"...".encode("base64") => base64.b64encode("...")
"...".encode("rot13") => do nothing (but display a warning?)
"...".encode("zlib") => zlib.compress("...")
"...".encode("hex") => base64.b16encode("...")
"...".encode("bz2") => bz2.compress("...")
"...".decode("base64") => base64.b64decode("...")
"...".decode("rot13") => do nothing (but display a warning?)
"...".decode("zlib") => zlib.decompress("...")
"...".decode("hex") => base64.b16decode("...")
"...".decode("bz2") => bz2.decompress("...")
"""
Unfortunately I don't know where is the syntax for writing fixers.

A more consistent alternative conversion:
"...".encode("base64") => codecs.encode("...", "base64_codec")
"...".encode("rot13") => codecs.encode("...", "rot_13")
"...".encode("zlib") => codecs.encode("...", "zlib_codec")
"...".encode("hex") => codecs.encode("...", "hex_codec")
"...".encode("bz2") => codecs.encode("...", "bz2_codec")
"...".decode("base64") => codecs.decode("...", "base64_codec")
"...".decode("rot13") => codecs.decode("...", "rot_13")
"...".decode("zlib") => codecs.decode("...", "zlib_codec")
"...".decode("hex") => codecs.decode("...", "hex_codec")
"...".decode("bz2") => codecs.decode("...", "bz2_codec")

On 25.04.2013 10:14, Nick Coghlan wrote:
> 
> Nick Coghlan added the comment:
> 
> A more consistent alternative conversion:
> 
> "...".encode("base64") => codecs.encode("...", "base64_codec")
> "...".encode("rot13") => codecs.encode("...", "rot_13")
> "...".encode("zlib") => codecs.encode("...", "zlib_codec")
> "...".encode("hex") => codecs.encode("...", "hex_codec")
> "...".encode("bz2") => codecs.encode("...", "bz2_codec")
> 
> "...".decode("base64") => codecs.decode("...", "base64_codec")
> "...".decode("rot13") => codecs.decode("...", "rot_13")
> "...".decode("zlib") => codecs.decode("...", "zlib_codec")
> "...".decode("hex") => codecs.decode("...", "hex_codec")
> "...".decode("bz2") => codecs.decode("...", "bz2_codec")
It would be better to add back the aliases we had for these codecs.

Sure, that's what issue 7475 is about, and if we do that, then the fixers can be simplified to just replace the method with the function call for the known set of non-text-model related codecs.
However, I also wanted to make a note of what the fixers should look like for a version of the fixer that can provide compatibility with 3.2+ rather than relying on the aliases being restored in 3.4

> A more consistent alternative conversion:
What advantages `codecs.encode("...", "base64_codec")` has comparing with `base64.b64encode("...")`? The latter is at least more portable and powerfull (it allows to specify altchars).
I think that main problem with issue 7475 is that people don't think about a different (actually the most obvious) way to do base64 encoding.

Switch direction of dependency to make this fixer rely on restoring the codec aliases in issue 7475 first.

Attached diff shows a proof of concept fixer for the encode case.
It could be adjusted fairly easily to also handle decode methods (by including an alternative in the pattern and also capturing the method name)
I'm sure how useful such a fixer would be in practice, though, since it only triggers when the codec name is passed as a literal - passing in a variable instead keeps it from firing.

On 7 November 2013 00:06, Nick Coghlan <report@bugs.python.org> wrote:
> I'm sure how useful such a fixer would be in practice, though, since it only triggers when the codec name is passed as a literal - passing in a variable instead keeps it from firing.
Oops, that should say "I'm *not* sure" :)

After thinking about this some more, perhaps a -3 warning in 2.7 would be a
better solution? That would be more robust, as it could complain any time
unicode.encode produced unicode and str.decode produced str and point users
to the codecs module level functions as a forward compatible alternative.
Producing Py3k warnings when calling unicode.decode and str.encode under -3
would also be appropriate (although those warnings may already exist).

Due to the data driven nature of this particular incompatibility, I'm rejecting this in favour of the Py3k warning based approach in issue 19543.