Sorry for top-posting, but I'm writing this in Outlook Web Access.
To keep the discussion quoted below constructive, I'd like to know what is the opinion of ChucK developers about copying the module import mechanisms of Python, which (to me) appears conceptually simple and at the same time flexible enough to trade off namespace cleanness against minimizing keystrokes according to every user's needs.
There is a hierarchy of "packages" (directories) containing nested packages or "modules" (source files) which, when imported (and therefore executed) bind named objects in the global namespace.
A reload() built-in function can reinitialize a module object from sources, without affecting existing function, class, module etc. objects from the previous version which are garbage collected in due time.
The import statement itself has variants which, after loading and executing the module file to initialize the module object, differ in the names they create and can have different purposes.
1) To avoid namespace pollution as much as possible:
import somepackage.somemodule
x=somepackage.somemodule.someclass(somepackage.somemodule.somefunction())
A module or package object is created and bound as "somemodule" in the global namespace; references to its content must be qualified, which is safe and explicit but verbose.
2) To avoid qualifying names:
from somepackage.somemodule import somefunction, someclass
x=someclass(somefunction())
from somepackage import somemodule
x=somemodule.someclass(somemodule.somefunction())
Each of the listed objects is added to the global namespace; the enclosing module or package isn't directly accessible.
3) To avoid listing identifiers:
from somepackage.somemodule import *
x=someclass(somefunction())
Spilling all names in a module, sight unseen, into the global namespace is obviously expedient but obviously dangerous; for interactive sessions which have neither complex library dependencies nor many names of their own it can be an acceptable practice.
4) To change and shorten identifiers:
import somepackage.somemodule as spsm
x=spsm.someclass(spsm.somefunction())
from somepackage.somemodule import somefunction as bar, someclass as foo
x=foo(bar())
Using "as", one can specify what names are put into the global namespace. Apart from being able to fix conflicting or unpleasant names, being able to use very short or fancy names should be useful for live coding.
Two advanced Python features that might be unneeded or replaced by different mechanisms are the customization of packages with a special file (__init__.py) listing which subdirectories are nested packages and which are not, and the customization of a module's exported symbols list through the special __all__ variable.
The only significant complication of Python import statements, which I suggest not adopting, is the use of relative paths with leading dots representing the enclosing packages of the current module: module "a.b.c.qwerty" should import "a.asdfg" with an absolute path like any other script, not the ugly and context-sensitive "...asdfg".
Python unfortunately started with relative imports as the default, but a new language like ChucK can learn from the experience; see http://www.python.org/dev/peps/pep-0328/
.
Regards,
Lorenzo Gatti
________________________________
Da: chuck-users-bounces@lists.cs.princeton.edu per conto di Kassen
Inviato: lun 03/09/2007 13.05
A: robin.escalation@acm.org; ChucK Users Mailing List
Oggetto: Re: [chuck-users] ChucK article(s)
On 9/3/07, robin.escalation