Skip to content

RFE: Warn about implicit Unicode conversions which could raise an exception #2182

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

Closed
Herst opened this issue Sep 25, 2016 · 1 comment
Closed

Comments

@Herst
Copy link
Contributor

Herst commented Sep 25, 2016

What I'm looking look for is basically a solution to the following SO question concerning problematic implicit conversions into unicode (in Python 2, I guess in Python 3 the equivalent problem with bytes to string conversions exists).

Summary of the SO question: I have a large existing projects where people weren't thinking much about Unicode and happily mixing encoded strs and unicode together without thinking twice about telling the decoder what the encoding used is and what to do with byte sequences which can't be decoded. Apparently I'm not the only one with the problem if you do a SO search or search for the horrible hack I mentioned in the SO question.

Now it would be great if e.g. there was a mypy parameter with which all implicit conversions into unicode (which also means that the programmer didn't explicitly state any encoding) would raise a warning, including the examples from the SO post:

# potentially problematic cases if someStr can also have non-ASCII characters in it
u"foo" + someStr
u"foo{}".format(someStr)

Note that I don't think that mypy should be making guesses about the content of the strings. Also, this RFE is probably related to #1141.

/edit: I just noticed that in python/typing#208 such solutions were already being discussed. Sorry for not noticing it earlier, think of this post here as an argument in favor of the strict approach then.

@gvanrossum
Copy link
Member

Thanks! I think we have enough issues open for this topic already (you found both of them) so I'm going to close this one. We're going slowly here but I have a good hope that we'll end up in a good spot with support for your use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants