Movatterモバイル変換
[0]ホーム
other python ideas
Andrew Dalkedalke at acm.org
Tue Apr 10 00:01:47 EDT 2001
Douglas Alan:>alias StringIO = cStringIO>try:> dummy = StringIO::someObject>except ImportError:> alias StringIO = StringIODoesn't this introduce the same problems you have with import?Specifically, you may end up with lots of "alias" statementswhich are unneeded by the module?It's also somewhat awkward in that you need to know an objectinside of the cStringIO/StringIO module for which to test.>or>>try:> StringIO = __import__("cStringIO")>except ImportError:> StringIO = __import__("StringIO")Not as nice looking with more complicated importstry: import Some.Patented.Module as ModuleXexcept ImportError: import My.Non.Patented.But.Slower.Module as ModuleXwhere you'll need ModuleX = __import("Some.Patented.Module").Patented.ModuleBut then, I've never liked that aspect of __import__.Regardless, then in your proposal later on you would use StringIO::StringIOThat means the implementation would need to first check ifStringIO is defined in the module and, if not, do the__import__.>> Or the not so common practice of>> [call trace example]>The same way you have just done it above, only without the import>statement and replace>> math = TraceCalls(math)>>with>> math = TraceCalls(__import__("math"))>>If in "math::foo", "math" turns out to refer an object other than a>module object, the language can still go with the flow, just like in>normal Python.So your construct of "X::Y" acts like if X exists: return X.Y else: __import__(X).YWhat about multilevel imports, say, xml.sax.handler? Could I use xml.sax::handler.ContentHandleror would I need to do xml::sax::handler.ContentHandler ?What if xml.sax is reallyclass sax: def __getattr__(self, name): import new return new.module(name)>Personally, I hate maintaining import lists. As a general>rule, I think it is bad to have to maintain the same information in>two different places.But it isn't the same information. One says that a name refersto a module, or a class, or an instance, or a function. Theother one says what to do with the name. def what_is(obj): print "This is", obj.__doc__ import math what_is(math) math = math.cos what_is(math) class math: pass what_is(math) math = math() what_is(math)Hmm. Thinking about this. How would you implement import math what_is(math)in your scheme? Perhaps as what_is(math::)?> Having to do so results in dead code that loads unused modules.I mentioned your "alias" has the same problem.There are tools which address unneeded imports. One was announcedjust a few days ago. A couple years ago I worked on mods tokwparser's lint program to support 1.5 syntax and gave Guido alist of a few dozen module references to delete.Even with this there will be cruft functions, classes, etc.which won't be fixed with this proposal, so it tries to solvepart of the problem without really addressing the whole thing.(Oh, and I helped with the code coverage program distributedin the Tools section to help that more general case :)>Also, I know people who won't use Python because they>want to be able to reload modules reliably, as you can on a Lisp>Machine.The quick answer is to let them work on Lisp Machines. Nowconsider:import spamdef f(x, eggs = spam.eggs): return eggs(x) * eggs(x+1)Because f's default value for eggs is defined at module importtime there is no way to reload(spam) and have f's functionredefined. Instead, you need to do a reload of this module aswell.Your proposal would change this todef f(x, eggs = spam::eggs): return eggs(x) * eggs(x+1)but still have the same problem that a reload(spam) won'trebuild f. So you don't fully solve the problem you wantto solve.It's even worse when you have:# viking.pyimport spamclass Parrot: def __init__(self, eggs = spam.eggs): self.eggs = eggs def f(self, x): return self.eggs(x) * self.eggs(x+1) ----% python>>> import viking>>> bird = Viking.Parrot()>>> # oops! edit spam to fix a bug in eggs>>> import eggs>>> reload(eggs)>>> reload(viking) # just to be safe>>> bird.f(9)# returns wrong answer because bird keeps a reference to the *old*# Viking.Parrot definition and the instance keeps a reference to# the *old* eggs.>>>So you are only fixing one part of a larger issue, which isrebuilding everything in Python dependent on a module.> Unfortunately, the Common Lisp module system is unbearably> complex.Whereas Python's system is quite easy to explain and worksjust about like everything else namespace related.And I must confess to not knowing anything other than themost elementary parts of Lisp. Then again, I can point toprecisely 1 person in all of computational biology andchemistry which use it... which is as many people as I knowusing Prolog or Ruby, and 1/2 the number I know of who haveused Smalltalk. I suspect that means something. Andrewdalke at acm.org
More information about the Python-listmailing list
[8]ページ先頭