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
2to3 fixers for missing codecs #62023
Comments
Quoting Victor Stinner from msg106669: """ "...".encode("base64") => base64.b64encode("...") "...".decode("base64") => base64.b64decode("...") Unfortunately I don't know where is the syntax for writing fixers. |
A more consistent alternative conversion: "...".encode("base64") => codecs.encode("...", "base64_codec") "...".decode("base64") => codecs.decode("...", "base64_codec") |
On 25.04.2013 10:14, Nick Coghlan wrote:
It would be better to add back the aliases we had for these codecs. |
Sure, that's what bpo-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 |
What advantages I think that main problem with bpo-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 bpo-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:
Oops, that should say "I'm *not* sure" :) |
After thinking about this some more, perhaps a -3 warning in 2.7 would be a Producing Py3k warnings when calling unicode.decode and str.encode under -3 |
Due to the data driven nature of this particular incompatibility, I'm rejecting this in favour of the Py3k warning based approach in bpo-19543. |
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: