Skip to content
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

change uses of StringIO #22

Open
daira opened this issue Aug 13, 2014 · 6 comments
Open

change uses of StringIO #22

daira opened this issue Aug 13, 2014 · 6 comments

Comments

@daira
Copy link
Contributor

daira commented Aug 13, 2014

E.g. [c]StringIO.StringIO should be changed to six.BytesIO.

(moved from mitsuhiko/python-modernize#17 )

@takluyver
Copy link
Contributor

Again, I think we should (at least by default) avoid trying to guess what the user wants. We've got a number of places in IPython where we use io.StringIO on Python 3 and StringIO.StringIO on Python 2. An off-by-default fixer might be OK, though.

@brettcannon
Copy link
Contributor

I just ran into this myself and the solution should depend on whether --no-six is specified. If no six is desired then you should probably use io.StringIO as a >= Python 2.6 solution.

@takluyver
Copy link
Contributor

I don't think that's quite right:

  • --no-six should mean "I don't want to use six", not a proxy for "this only needs to support Python 2.6 and above". I see your issue Support Python 2.6 and higher only #33, so let's discuss this more there.
  • The right answer for this doesn't just depend on what versions of Python you support. E.g. IPython only supports 2.7 and 3.3+, but we still use StringIO.StringIO in quite a few places on Python 2, because it accepts str, whereas io.StringIO is strict about only accepting unicode.

@brettcannon
Copy link
Contributor

Farther along in my Pylint port and I have run into the issues that has led to IPython keeping [c]StringIO.StringIO around. Unfortunately this is one of those places where the Python 2 API was so lenient it doesn't translate well to a str/bytes dichotomy.

@daira
Copy link
Contributor Author

daira commented Aug 18, 2014

If we add an option, say --careful-unicode, for transforming code that is already careful about string types (as suggested in #31), then that option should probably enable a StringIO -> six.BytesIO fixer by default. In other cases we should just leave StringIO alone to be changed manually.

@graingert
Copy link
Member

there's since been a six.StringIO

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

No branches or pull requests

4 participants