Movatterモバイル変換
[0]ホーム
other python ideas
Douglas Alannessus at mit.edu
Mon Apr 9 20:17:50 EDT 2001
rcameszREMOVETHIS at dds.removethistoo.nl (Robert Amesz) writes:> Getting rid of import statements is *evil*. It means the dependencies> in your code will be hidden from others.How's that? All you'd have to do is grep for "::". (Remember, Ispecifically said that every usage of an object from another modulewould have an explicit module identifier.) It's not like importstatements all have to be at the top of the file in Python code as itis. They certainly aren't in my code.> Also, install and freeze packages have a harder determining what> modules are needed (which is hard enough as it is).It would be no harder than it is now. "module::foo" would just besyntactic sugar for "__import__("module").foo" (along with a moreefficient implementation technique).> If unused imports bother you, well, the other day I saw an> announcement here for a Python code checker. Perhaps it can check> that too. If not, perhaps its maker(s) may include it in the next> version if you ask it nicely enough. ("Please? Pretty please? ;-) )I'd rather just specify my modules at each use. But certainly achecker would be nice in lieu of this.> >Another problem is that if you import individual objects from a> >module, and then you reload the module, the individual objects> >remain out of date. This causes you to end up trying in the> >debugger to track down bugs that turn out to debugger-only bugs.> Blame the debugger, not Python's module syntax. The debugger really> should start from scratch if you've edited a module, otherwise> you're actually modifying the program while it is still> running. Very unsafe, and there's no general way to fix that.Sure there is. And I don't want to start from scratch. A LispMachine just runs one big Lisp (even the OS is in that one big Lisp)that never goes away until you reboot it. In such an environment,being able to reliably reload modules is essential. It is very usefulto have this work reliably for less severe environments too. Onemight argue that the complexity is not worth the gain, but I wasn'targuing for anything more complicated -- just something different.Recall again that I'm not suggesting that Python be changed, at leastnot before Python 3k. I'm just pointing out what would make a betterlanguage.|>oug
More information about the Python-listmailing list
[8]ページ先頭