other python ideas

[Andrew Dalke]

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 Python

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)


> 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)

] One of the things that makes it interesting, is exactly how
] much Guido has managed to exploit that one implementation
] trick of 'namespaces'.
         http://www.amk.ca/quotations/python-quotes/page-1.html

BTW, I've also used code similar to that second example to
implement a proxy system where the "module" was actually
replaced with calls to code on another machine.

                    Andrew
                    dalke at acm.org