A significant difference in usage between Python and ChucK is that Python libraries and extensions tend to be either an integral part of a project or stable shared dependencies of other libraries or applications, while most ChucK libraries can be expected to be 1) experimental or hacked versions of standard library modules, overriding the originals 2) foreign and/or hacked code adopted from other people 3) personal work-in-progress toolboxes. Therefore, most Python libraries are located in some application directory or in the global Lib directory of the interpreter and in both cases controlling the search path is unnecessary; on the contrary ChucK libraries would be rarely appropriate for a global or shared search path and would be often specified differently for specific invocations. Java is very sensitive to library path mistakes (e.g. the "same" class, loaded from two different libraries, is fatally different) and has a very complex search path which is usually specified in a rather explicit and predictable way from the command line and sometimes with references inside libraries. The CLASSPATH environment variable that was initially recommended has become unpopular because it makes application behaviour dependent on which completely unrelated scripts have been run and how they altered this global but transient search path. ChucK can be expected to have the same kind of problems: environment variables are more complex than a global library repository and less reliable than self-contained scripts that invoke the interpreter with the appropriate libraries for different purposes. The only possible advantage of environment variables is that they can be invisible and allow users to avoid invoking scripts or cluttering the command line with options, but this invisibility is also a liability (what if you realize from sudden errors or silence that you used the wrong terminal window where variables are different? What if you need to look up these variables because you forgot?). There are two mostly orthogonal important design decisions about library search paths on the command line: whether to specify directories (including all their content) or single files and whether the list of library locations should be in a command line option or indirectly referenced from a configuration file. Regards, Lorenzo Gatti ________________________________ Da: chuck-users-bounces@lists.cs.princeton.edu per conto di robin.escalation Inviato: lun 03/09/2007 19.35 A: chuck-users@lists.cs.princeton.edu Oggetto: Re: [chuck-users] Importing in Python - was: ChucK article(s) I will not quote all of Gatti Lorenzo's post, which basically suggested adding (most of) the Python namespace and import features into ChucK. I think this would be wonderful and furthermore concur with those features that needn't be implemented. I would like to point out that the import mechanism relies on having a list of paths to search in order to find the libraries. This would also be needed in Chuck. Specifying such a list could happen in an environment variable, configuration file, command-line argument, or some combination of all three. -- robin _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users https://lists.cs.princeton.edu/mailman/listinfo/chuck-users