A Workshop on Python at NIST

Michael McLay (mclay@eeel.nist.gov)
Thu, 29 Sep 94 16:47:54 EDT

Guido will be visiting NIST as a guest researcher from mid October to
mid December. I would like to take advantage of his visit and invite
all interested parties to an informal workshop on Python at NIST. The
dates for the meeting are November 1-3. If you are interested in
attending please send me an email message before October 15th. The
meeting room I have at my disposal can hold up to 20 people which I
assume will be adequate for a workshop called on such short notice.
If we need more space I can probably find a larger meeting room.

I've assembled a strawman list of topics for discussion. New topics
and comments on the topics listed are certainly welcome.

1. Requirements for a "Safe" Python interpreter
2. A standard GUI module interface definition for Python
3. The requirements for persistent objects in Python
4. A Python engineering graphs package
5. The standard Python WWW interface
6. Embedding Python in a WWW client
7. Technical information management using Python
8. Support for dynamic loading of foreign language modules in Python
9. Replacing make, rcs, and cvs with Python
10. An Electronic Data Interchange library for Python
11. Discussing the formation of a Python Consortium

Guido's comments were:

> I haven't seen every topic here before but they sure are interesting
> topics, and it looks like most of my own favorite subjects are listed
> -- especially #s 1, 2, 3, 5, 6. What's your idea with #8 (dynamic
> loading)?
>
Guido added:
>
> 12. compiling Python to a more efficient form (hard -- but not
> impossible???)
>
> 14. static type checking (could help to the previous one)
>
> 15. the management of large collections of modules (too many
> Python scripts currently embed hard pathnames in their main
> file so they can find their subordinate modules)
>
> 16. improving the efficiency of Python (e.g. by using a different
> garbage collection scheme)
>
> 17. improving portability of Python code between Unix and non-Unix
> platforms (your #2 is a special case of this)

To clarify my idea #8 I wrote:

I would like to be able to add new C, C++, and Fortran based modules to
Python without having to recompile the Python executable. This may
already be possible on some systems, but I don't believe it is
possible using SUNOS 4.1.x. The primitive UNIX compiling and linking
technology may be at fault here. I don't claim expertise in this area
of software technology so I may have missed an obvious solution or
some reason why this isn't a good idea.

Guido replied with:

Actually, dynamic module loading does work on SunOS 4.1.3 using
exactly the same code as for Solaris 2 and IRIX 5 (it was even
pioneered on SunOS 4.1.3). I doubt you will be able to come up with a
platform independent implementation -- the current platform
independent interface (apart from the extension of the shared
libraries).

My problem still remains. I have to recompile python every time I add a
a new binary module? If not, how does it find the proper .so file to
search for the compiled code. There is also the problem of adding the
module name and function to the inittab.

On the afternoon of November 2nd there will be a short steering
committee meeting to discuss whether setting up a Python consortium
would help or hinder the advancement of the language. (Anyone can be
on the steering committee.)

Michael J. McLay
National Institute of Standards and Technology
Bld 220 Rm A357 (office), Bld 220 Rm B344 (mail)
Gaithersburg, Maryland 20899, (301)975-4099