2to3: Apply `imports` fixer. #3191

Merged
merged 2 commits into from Apr 6, 2013

Projects

None yet

3 participants

@charris
Member
charris commented Apr 2, 2013

The imports fixer deals with the standard packages that have been
renamed, removed, or methods that have moved.

cPickle -- removed, use pickle
commands -- removed, getoutput, getstatusoutput moved to subprocess
urlparse -- removed, urlparse moved to urllib.parse
cStringIO -- removed, use StringIO or io.StringIO
copy_reg -- renamed copyreg
_winreg -- renamed winreg
ConfigParser -- renamed configparser
__builtin__ -- renamed builtins

In the case of cPickle, it is imported as pickle when python < 3 and
performance may be a consideration, but otherwise plain old pickle is
used.

Dealing with StringIO is a bit tricky. There is an io.StringIO
function in the io module, available since Python 2.6, but it expects
unicode whereas StringIO.StringIO expects ascii. The Python 3
equivalent is then io.BytesIO. What I have done here is used BytesIO
for anything that is emulating a file for testing purposes. That is more
explicit than using a redefined StringIO as was done before we dropped
support for Python 2.4 and 2.5.

Closes #3180.

@charris charris 2to3: Apply `imports` fixer.
The `imports` fixer deals with the standard packages that have been
renamed, removed, or methods that have moved.

cPickle      -- removed, use pickle
commands     -- removed, getoutput, getstatusoutput moved to subprocess
urlparse     -- removed, urlparse moved to urllib.parse
cStringIO    -- removed, use StringIO or io.StringIO
copy_reg     -- renamed copyreg
_winreg      -- renamed winreg
ConfigParser -- renamed configparser
__builtin__  -- renamed builtins

In the case of `cPickle`, it is imported as `pickle` when python < 3 and
performance may be a consideration, but otherwise plain old `pickle` is
used.

Dealing with `StringIO` is a bit tricky. There is an `io.StringIO`
function in the `io` module, available since Python 2.6, but it expects
unicode whereas `StringIO.StringIO` expects ascii. The Python 3
equivalent is then `io.BytesIO`. What I have done here is used BytesIO
for anything that is emulating a file for testing purposes. That is more
explicit than using a redefined StringIO as was done before we dropped
support for Python 2.4 and 2.5.

Closes #3180.
09a52ed
@njsmith njsmith and 1 other commented on an outdated diff Apr 2, 2013
doc/cdoc/numpyfilter.py
@@ -13,7 +13,11 @@
import os
import textwrap
import optparse
-import cPickle as pickle
+
+if sys.version_info[0] >= 3:
+ import pickle
+else:
+ import cPickle as pickle.
@njsmith
njsmith Apr 2, 2013 Member

I don't think Python likes sentence punctuation.

@charris
charris Apr 2, 2013 Member
  1. . And I thought I fixed that... must have fat fingered something along the way.
@njsmith
Member
njsmith commented Apr 2, 2013

I'm wary about the doc-related code changes in general -- these are potential behavioural changes that travis doesn't test, right? Do we know the docs still build with this PR?

@charris
Member
charris commented Apr 2, 2013

Yeah, me to. I was going to test first but got hasty. I'll give it a shot.

@charris charris BUG: Fix stray '.' in import statement.
There was a stray period at the end of an import statement in
`doc/cdoc/numpyfilter.py`. Looks like a cut and paste error that
was fixed elsewhere but escaped there because the module isn't
tested. A search shows that this was the only spot in which the
error was still present.
4394515
@charris
Member
charris commented Apr 2, 2013

OK, I installed sphinxext from the repository and did make html. The run completed and the docs look good, or at least no worse. There were 559 warnings and several errors during the run but they were also present when I used a branch that didn't have this PR or the previous apply-import PR applied, so they have evidently been there for a while. The docs look like they could use some TLC.

@rgommers
Member
rgommers commented Apr 2, 2013

TLC definitely needed. The problem is that Sphinx and the autodoc extension go out of their way to prevent you from seeing where the warnings come from. Fixing that first would be much more useful than trying to work through all the warnings now.

@charris
Member
charris commented Apr 2, 2013

I have a suspicion that a lot of them are due to file names of the form xxx.yyy.zzz.rst and the extension stripping.

@njsmith
Member
njsmith commented Apr 6, 2013

Hmm, well, I guess this is good then? If we end up breaking scipy's docs or something then I'm sure we'll hear about it sooner or later :-)

@charris, merge if you think it's ready?

@charris charris merged commit 49a8902 into numpy:master Apr 6, 2013

1 check passed

default The Travis build passed
Details
@charris charris deleted the charris:2to3-apply-imports-fixer branch Apr 6, 2013
@charris
Member
charris commented Apr 6, 2013

OK, in it goes. The next one is simpler ;)

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