How to guard against bugs like this one?

[Terry Reedy]

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
>> that
>
>> 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