Let me preface everything by thanking you and all those who replied for their comments.
I have only one follow-up question (or rather, set of related questions) that I'm very keen about, plus a bit of a vent at the end. In <pan.2010.02.02.03.28...@remove.this.cybersource.com.au> Steven D'Aprano <ste...@remove.this.cybersource.com.au> writes: >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.) ~k [NB: as I said before, what follows begins to slide into a vent, and is quite unimportant; I've left it, for whatever grain of truth it may contain, as an grossly overgrown PS; feel free to ignore it, I'm *by far* most interested in the question stated in the paragraph right above, because it will give me, I hope, a better sense of where the biggest obstacles to fixing this problem lie.] P.S. Yes, I see the backwards-compatibility problem, but that's what rolling out a whole new versions is good for; it's a bit of a fresh start. I remember hearing GvR's Google Talk on the coming Python 3, which was still in the works then, and being struck by the sheer *modesty* of the proposed changes (while the developers of the mythical Perl6 seemed to be on a quest for transcendence to a Higher Plane of Programming, as they still are). In particular the business with print -> print() seemed truly bizarre to me: this is a change that will break a *huge* volume of code, and yet, judging by the rationale given for it, the change solves what are, IMHO, a relatively minor annoyances. Python's old print statement is, I think, at most a tiny little zit invisible to all but those obsessed with absolute perfection. And I can't imagine that whatever would be required to fix Python's import system could break more code than redefining the rules for a workhorse like print. In contrast, the Python import problem is a ticking bomb potentially affecting all code that imports other modules. All that needs to happen is that, in a future release of Python, some new standard module emerges (like numbers.py emerged in 2.6), and this module is imported by some module your code imports. Boom! Note that it was only coincidental that the bug I reported in this thread occurred in a script I wrote recently. I could have written both scripts before 2.6 was released, and the new numbers.py along with it; barring the uncanny clairvoyance of some responders, there would have been, at the time, absolutely no plausible reason for not naming one of the two scripts numbers.py. To the argument that the import system can't be easily fixed because it breaks existing code, one can reply that the *current* import system already breaks existing code, as illustrated by the example I've given in this thread: this could have easily been old pre-2.6 code that got broken just because Python decided to add numbers.py to the distribution. (Yes, Python can't guarantee that the names of new standard modules won't clash with the names of existing local modules, but this is true for Perl as well, and due to Perl's module import scheme (and naming conventions), a scenario like the one I presented in this thread would have been astronomically improbable. The Perl example shows that the design of the module import scheme and naming conventions for standard modules can go a long way to minimize the consequences of this unavoidable potential for future name clashes.) -- http://mail.python.org/mailman/listinfo/python-list
