How to guard against bugs like this one?

kj at
Wed Feb 3 03:36:49 CET 2010

In <mailman.1804.1265150872.28905.python-list at> Terry Reedy <tjreedy at> writes:

>On 2/2/2010 2:43 PM, kj wrote:
>> In<mailman.1795.1265135424.28905.python-list at>  Terry Reedy<tjreedy at>  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.

Thanks, this dispels some of the mystery.


More information about the Python-list mailing list