How to guard against bugs like this one?
tjreedy at udel.edu
Tue Feb 2 23:47:19 CET 2010
On 2/2/2010 2:43 PM, kj wrote:
> In<mailman.1795.1265135424.28905.python-list at python.org> Terry Reedy<tjreedy at udel.edu> writes:
>> On 2/2/2010 9:13 AM, kj wrote:
>>>> As for fixing it, unfortunately it's not quite so simple to fix without
>>>> breaking backwards-compatibility. The opportunity to do so for Python 3.0
>>>> was missed.
>>> This last point is to me the most befuddling of all. Does anyone
>>> know why this opportunity was missed for 3.0? Anyone out there
>>> with the inside scoop on this? Was the fixing of this problem
>>> discussed in some PEP or some mailing list thread? (I've tried
>>> Googling this but did not hit on the right keywords to bring up
>>> the deliberations I'm looking for.)
>> There was a proposal to put the whole stdlib into a gigantic package, so
>> import itertools
>> would become, for instance
>> import std.itertools.
>> Guido rejected that. I believe he both did not like it and was concerned
>> about making upgrade to 3.x even harder. The discussion was probably on
>> the now closed py3k list.
> Thanks. I'll look for this thread.
Stephen Hansen's post explains a bit more than I did. To supplement his
explanation: since print *was* a keyword, every use of 'print' in 2.x
denotes a print statement with standard semantics. Therefore 2to3
*knows* what the statement means and can translate it. On the other
hand, 'import string' usually means 'import the string module of the
stdlib', but it could mean 'import my string module'. This depends on
the execution environment. Moreover, I believe people have intentionally
shadowed stdlib modules. So. like it or not, 2to3 cannot know what
'import string' means.
Terry Jan Reedy
More information about the Python-list