Movatterモバイル変換


[0]ホーム

URL:


other python ideas

Douglas Alannessus at mit.edu
Mon Apr 9 22:44:35 EDT 2001


"Andrew Dalke" <dalke at acm.org> writes:> Douglas Alan:> >On the other hand, I don't think that having to use "import"> >statements is necessarily a good thing.  I'd prefer to see some sort> >of syntax like> >   mymodule::foo(a, b, c)> >This syntax would invoke mymodule.foo(), and would load module> >"mymodule" it if it wasn't already loaded.> How would that work with the common idiom of> try:>   import cStringIO as StringIO  # optional module implemented in C> except ImportError:>   import StringIO  # slower implementation in Pythonalias StringIO = cStringIOtry:   dummy = StringIO::someObjectexcept ImportError:   alias StringIO = StringIOortry:   StringIO = __import__("cStringIO")except ImportError:   StringIO = __import__("StringIO")> Or the not so common practice of> import math> class TraceCalls:>   def __init__(self, module):>     self.__module = module>   def __getattr__(self, name):>     x = getattr(self.__module, name)>     if is_callable(x):>       print "Request for callable:", x>       return TraceCallable(name, x)>     print "Return value for:", x> class TraceCallable:>   def __init__(self, name, callable):>     self.__name = name>     self.__callable = callable>   def __call__(self, *args, **kwargs):>     print "Calling", self.__name>     x = self.__callable(*args, **kwargs)>     print "Return from", self.__name, "with", x>     return x> math = TraceCalls(math)The same way you have just done it above, only without the importstatement and replace   math = TraceCalls(math)with    math = TraceCalls(__import__("math"))If in "math::foo", "math" turns out to refer an object other than amodule object, the language can still go with the flow, just like innormal Python.> > You'd probably also want> >some sort of module aliasing notation so you could use> >  alias m my_really_long_named_module> >  m::foo(a, b, c)> That will deal with my first case a the expense of a more> compicated language, but not the second.  The problem I see> with your proposal is it ignores Python's strenth in> treating almost all namespaces - module, class, and instance> -- the same.  To quote Tim Peters (from 16 Sep 1993)I don't ignore it.  I like the fact that Python is orthogonal in thisfashion.  But sometimes you can't get everything you like in onelanguage.  Personally, I hate maintaining import lists.  As a generalrule, I think it is bad to have to maintain the same information intwo different places.  Having to do so results in dead code that loadsunused modules.  Also, I know people who won't use Python because theywant to be able to reload modules reliably, as you can on a LispMachine.  Unfortunately, the Common Lisp module system is unbearablycomplex.  I'd think to think that there's a happy medium that wouldprovide the important features of the Common Lisp module system whilemaintaining most of the simplicity of the Python module system.As always, programming languages are about trade-offs, so there isunlikely to be one correct answer.  But it pays, I think, to considercarefully what has been gained and lost with each design decision.Thanks for your feedback.  It is surely food for thought.|>oug


More information about the Python-listmailing list

[8]ページ先頭

©2009-2025 Movatter.jp