In <mailman.1804.1265150872.28905.python-l...@python.org> Terry Reedy <tjre...@udel.edu> writes:
>On 2/2/2010 2:43 PM, kj wrote: >> In<mailman.1795.1265135424.28905.python-l...@python.org> Terry >> Reedy<tjre...@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. Thanks, this dispels some of the mystery. ~K -- http://mail.python.org/mailman/listinfo/python-list