NOTE - below is the pre-meeting prospectus. See:

NIST Python Workshop, Software Mgmt Session Report

for the post-workshop report! ken, 21-Nov-1994.

Subject: Python Software Mgmt Session Prospectus From: ken.manheimer@nist.gov (Ken Manheimer) To: mclay@eeel.nist.gov, guido@eeel.nist.gov Date: Wed, 2 Nov 94 09:12:36 EST Organization: National Institute of Standards and Technology Python Software Mgmt Session Prospectus Ken.Manheimer@nist.gov, 2-Nov-1994. Python has an extraordinary "dynamic range", as someone on the mailing list recently phrased it. The language is well suited for implementation of large, elaborate systems, as well as small, simple scripts. This session is aimed at identifying what python needs to fill out support for managing software, large scale and small, and how best to accomodate these needs. I think we should take the opportunity, at this early stage, to try to focus on what inherent features may be lacking, or need refinement, in the language foundation, looking for intrinsic hooks or features whose incorporation would provide the most leverage as a foundation for further development. We may need to identify priorities for higher-level layers, in order to direct our focus on what is necessary at the primitive level... Here are some potential items: 1: Modularity: faculties which promote large-grain code modularity (* at the file, not function, level) (import) 2: Intrinsic documentation: features which enable code assessment and organization (e.g., doc-string-style annotation, topical categorization, code finding tools), so that the language can itself be employed to help assess and organize code 3: Programmer interface: more generally, the faculties necessary to facilitate entering, editing, and controlling application of code (emacs interface for editing and debugging, obj/env browsers, refinements of the interpreter loop) 4: Package Customization Interface: facilities by which packages can offer the user customization options, preferably without requiring the user to load or edit the module itself. (: Ramifications of other sessions - eg., of persistent code objects; compilation/optimizations; http widgets for programmer interface, etc.) [* Fine-grain function level scoping is more of a fundamental language issue than one of software mgmt.] Here are a few of my ideas on these subjects... 1: Large-grain modularity - import I have on several occasions tripped over a constraint in import, which can be remedied by a small change, and guido has brought up an issue which suggests another change. I occasionally need to import a specific module from a specific directory, but import does not give me direct control over that. While i can adjust the sys.path value to target the specific file, that would require at least two distinct statements. I think that path-specific import should be implemented as an atomic operation. Along a separate line, guido has pointed out that it would be useful to be able to affiliate and treat suites of related modules monolithically. I have a proposal for a simple extension of the import function that would conform well with the current paradigms, and provide some aspects of association of groups of modules (including a common interface) without preventing them from being used separately. I'll detail this separately. 2: Intrinsic documentation: While much can be done with a discriminating code-browsing interface, purely on the basis of language (and comment) syntax, some properties that can be incorporated directly in objects would promote the benefits of applying the language, itself, to explore and handle python code. : Doc strings, as in emacs lisp, to enable meaningful apropos-style (and better) searches; : Generally, hooks by which the language can be used to do the manipulation - it may be appropriate to ask, "how do the language structures need to be extended, if at all, to make internal object features exposed to procedures of language itself?" 3: Programmer interface: I am referring to low-level hooks necessary for use by higher-level mechanisms, like the extensions guido added to enable the bdb and profiling interfaces. It's important to pay attention here to the leverage we can get from existing (or prospective) tools. - Eg, the emacs "Global Universal Debugger" (gud) interface is very powerful, and it might not take much change to python, if any, to enable hookup to it. - Similarly, what prospects in our GUI plans should we seek to capitalize upon for programmer interfaces? There's no point in duplicating those efforts!