[chuck-users] Importing in Python - was: ChucK article(s)

[Gatti Lorenzo]

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 at lists.cs.princeton.edu per conto di Kassen
Inviato: lun 03/09/2007 13.05
A: robin.escalation at acm.org; ChucK Users Mailing List
Oggetto: Re: [chuck-users] ChucK article(s)

On 9/3/07, robin.escalation <robin.escalation at acm.org> wrote: 


	As I understand it, in ChucK there is nothing similar to an import.
	Files do not have explicit namespaces, though one is created if a
	file is sporked as a shred. But this is not addressable, it merely
	keeps private data in each process from colliding. A further 
	limitation is there can be only one public class in a file.


Yes, you are right. As you might've seen in the list archives; we just went trough a process where everybody could list his/her wishes and sugestions for chucK and a import/inclusion process turned out to be very high on that list. 

Likely this will (have to?) bring a more sophisiticated namespace method with it. In my own experience the current method covers the needs of chucK. Another matter is that in the past far more people ran into a desire to have seperate elements share their namespace then that ran into the desire for more seperation. Perhaps this will change as imports/inclusions make it easier and more inviting to start larger projects. 
 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 8472 bytes
Desc: not available
Url : http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070903/c8520b0f/attachment.bin