other python ideas

[Douglas Alan]

"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 Python

alias StringIO = cStringIO
try:
   dummy = StringIO::someObject
except ImportError:
   alias StringIO = StringIO

or

try:
   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 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.

> > 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 this
fashion.  But sometimes you can't get everything you like in one
language.  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.  Having to do so results in dead code that loads
unused modules.  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.  Unfortunately, the Common Lisp module system is unbearably
complex.  I'd think to think that there's a happy medium that would
provide the important features of the Common Lisp module system while
maintaining most of the simplicity of the Python module system.

As always, programming languages are about trade-offs, so there is
unlikely to be one correct answer.  But it pays, I think, to consider
carefully what has been gained and lost with each design decision.

Thanks for your feedback.  It is surely food for thought.

|>oug