Repository navigation
incorrect renaming in imports #49159
Description
| BPO | 4909 |
|---|---|
| Nosy | @loewis, @benjaminp |
| Files |
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:
assignee = None
closed_at = <Date 2009-01-10.21:12:25.024>
created_at = <Date 2009-01-10.19:32:32.953>
labels = ['expert-2to3']
title = 'incorrect renaming in imports'
updated_at = <Date 2009-01-10.21:12:25.016>
user = 'https://github.com/loewis'bugs.python.org fields:
activity = <Date 2009-01-10.21:12:25.016>
actor = 'benjamin.peterson'
assignee = 'none'
closed = True
closed_date = <Date 2009-01-10.21:12:25.024>
closer = 'benjamin.peterson'
components = ['2to3 (2.x to 3.x conversion tool)']
creation = <Date 2009-01-10.19:32:32.953>
creator = 'loewis'
dependencies = []
files = ['12681']
hgrepos = []
issue_num = 4909
keywords = ['patch']
message_count = 4.0
messages = ['79568', '79576', '79577', '79578']
nosy_count = 2.0
nosy_names = ['loewis', 'benjamin.peterson']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue4909'
versions = []
Activity
loewis commentedon Jan 10, 2009
The fragment
try:
import cStringIO as StringIO
except ImportError:
import StringIO
s=StringIO.StringIO()
gets rewritten to
try:
import io as StringIO
except ImportError:
import io
s=io.StringIO()
Unfortunately, that code fails to work: the first import succeeds,
actually binding StringIO; the name io is unbound and gives NameError.
Apparently, the fixer choses to replace all occurrences of StringIO with
io; it should extend this replacement to "as" clauses.
My work-around is to import as _StringIO in both cases, and then refer
to the module as _StringIO.
benjaminp commentedon Jan 10, 2009
Tricky. I only solution I can think of is replacing cStringIO with
_stringio or just refusing to replace StringIO usage once cStringIO has
been seen. The latter seems like the best solutions.
loewis commentedon Jan 10, 2009
If there is no straight-forward solution, we should close it as "won't
fix", and encourage users to work around.
benjaminp commentedon Jan 10, 2009
Ok. I will close this for now. This is a very common construct; if we
get more bug reports, we can reconsider. (I'm attaching the patch I used
to "fix" this for future reference.)