How to guard against bugs like this one?
in [Python]
|
From: Terry Reedy on 2 Feb 2010 17:47 On 2/2/2010 2:43 PM, kj wrote: > In<mailman.1795.1265135424.28905.python-list(a)python.org> Terry Reedy<tjreedy(a)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
From: Steven D'Aprano on 2 Feb 2010 20:49 On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote: > I did not propose obvious module names. I said obvious names like > email.py are bad; more descriptive names like send_email.py are better. But surely send_email.py doesn't just send email, it parses email and receives email as well? -- Steven
From: kj on 2 Feb 2010 21:35 (For reasons I don't understand Stephen Hansen's posts don't show in my news server. I became aware of his reply from a passing reference in one of Terry Reedy's post. Then I found Hansen's post online, and then an earlier one, and pasted the relevant portion below.) > First, I don't shadow built in modules. Its really not very hard to avoid. ....*if* you happen to be clairvoyant. I still don't see how the rest of us could have followed this fine principle in the case of numbers.py prior to Python 2.6. > Secondly, I use packages structuring my libraries, and avoid junk > directories of a hundred some odd 'scripts'. <small>(I feel so icky now...)</small> > Third, I don't execute scripts in that directory structure directly, but > instead do python -c 'from package.blah import main; main.main()' or some > such. Usually via some short-cut, or a runner batch file. Breathtaking... I wonder why the Python documentation, in particular the official Python tutorial, is not more forthcoming with these rules. ~K
From: kj on 2 Feb 2010 21:36 In <mailman.1804.1265150872.28905.python-list(a)python.org> Terry Reedy <tjreedy(a)udel.edu> writes: >On 2/2/2010 2:43 PM, kj wrote: >> In<mailman.1795.1265135424.28905.python-list(a)python.org> Terry Reedy<tjreedy(a)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
From: Steve Holden on 2 Feb 2010 22:53
kj wrote: > > (For reasons I don't understand Stephen Hansen's posts don't show > in my news server. I became aware of his reply from a passing > reference in one of Terry Reedy's post. Then I found Hansen's post > online, and then an earlier one, and pasted the relevant portion > below.) > > > >> First, I don't shadow built in modules. Its really not very hard to avoid. > > ...*if* you happen to be clairvoyant. I still don't see how the rest of us > could have followed this fine principle in the case of numbers.py > prior to Python 2.6. > Clearly the more you know about the standard library the less likely this is to be a problem. Had you been migrqating from an earlier version the breakage would have alerted you to look for some version-dependent difference. >> Secondly, I use packages structuring my libraries, and avoid junk >> directories of a hundred some odd 'scripts'. > > <small>(I feel so icky now...)</small> > Be as flippant as you like, but that is good advice. >> Third, I don't execute scripts in that directory structure directly, but >> instead do python -c 'from package.blah import main; main.main()' or some >> such. Usually via some short-cut, or a runner batch file. > > Breathtaking... I wonder why the Python documentation, in particular > the official Python tutorial, is not more forthcoming with these > rules. > Because despite the fact that this issue has clearly bitten you badly enough to sour you against the language, such issues are remarkably rare in practice and normally rather easier to debug. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ |