I propose giving a presentation based on my introductory essay on how Python is developed as found at http://python.org/dev/dev_intro.html (the uploaded file is actually the reST file used on the site as of this post).

The presentation would give a general overview of how python-dev "works". After that it would cover how various things (new stdlib modules/features, new language features, etc.) are dealt with and the steps needed to get them accepted (and thus how the process works). It finishes by explaining various ways people can contribute to Python's development.

The main goal is to demystify Python's development and to get more people involved.

A short (30-minute) introduction to the iterator and generator constructs added in Python 2.2: How an 'iterable' is different from a 'sequence', and why (and when) one should use a generator. The session requires some Python knowledge, but it should really be considered introductory-level.

Targeted at intermediate Python programmers seeking to understand metaclasses, this presentation will focus primarily on when, where and how metaclasses are an appropriate solution to programming problems.

We will look at the problem areas best served by meta-class operations. We will cover the nature and implementation of metaclasses sufficient to serve as a basis for further study, but will not focus unduly on the minutiae of implementation. In short, we will be learning enough about the area to allow you to allow you to feel comfortable when you discover metaclasses in the wild, and to determine whether to invest in further exploration of the topic.

New-style classes (or 'unified types') were introduced in Python 2.2 as part of the type/class unification. Although they provide many new features and mechanisms, including the ability to subclass C types in Python, their optional nature and limited documentation conspire to leave them underused and underexposed. This tutorial-style session is an attempt to remedy this by explaining in detail why new-style classes exist, how they can and should be used. Descriptors, properties, static- and class-methods, super() and metaclasses are all extensively covered. In spite of being stiled a tutorial, the pace will be high and familiarity with Python some knowledge of C will be expected.

• Introduction / old-style classes
  To understand new-style classes, some implementation details are required. We look at the "classic classes" situation first, briefly explain the type/class dichotomy, the C implementation and bound/unbound methods.
• New-style C types
  The C implementation of new-style classes is briefly explained, explaining 'object' and the need for new inheritance rules, descriptors and the __new__ method.
• super()
  super() is covered extensively, explaining why it is necessary to have super and when it should be used.
• Descriptors
  An important part of the mechanisms behind being able to subclass types, descriptors allow a new level of control in Python classes. We cover how they are used for properties and methods, including static- and class-methods.
• Subclassing C types
  The original outset of new-style classes was to heal the type/class dichotomy and allow types (implemented in C) to be subclassed in Python. However, just because we can does not mean we must. The limitations of subtyping are covered, as well as the downsides. Subtyping in C is also covered.
• Metaclasses
  The wonderful new tool of metaclasses, which allow much more control over how classes behave, is often considered to be complex and frightening. The fundaments of metaclasses are explained, showing how they both are and are not like regular classes, and some examples are given of practical use of metaclasses.
• Conclusion and questions

OS X is a complicated hybrid of technologies from NeXT, MacOS, \*BSD. Unforunately for developers, this means that there are more APIs and buzzwords than you can shake a stick at. 60 minutes of MacPython is a whirlwind tour of how to hack all those neat frameworks from Python.

This talk is for anyone who owns a Mac, or is interested in how things are "on the other side". Focal points of the talk are Darwin (UNIX-like-stuff), AppleEvents (application automation), and PyObjC + Cocoa (GUI framework). The talk will finish with a few words about the MacPython community and where to find it (pythonmac-sig and pythonmac.org).

This presentation is intended for novice pythonistas preparing to package up their own Python modules and programs for distribution for the first time.

The focus will be on appropriate and simple use of Python's own standard library "distutils" package, with the main emphasis being given to cross-platform applications and libraries of modules.

The presentation will cover general packaging considerations, directory issues, setting up a user-friendly setup.py, with coverage of the metadata arguments and content specification, the ins and outs of manifest and manifest.in, how to run sdist, when and why to use bdist.

Alternative applications and resources for program packaging and distribution, particularly platform-specific ones (including py2exe for Windows machines, Packager for Mac OS X, McMillan's "installer", and tools for preparing "point and click" GUI installers for end-users) will be mentioned, but not covered in depth.

Python releases for Windows up to and including Python 2.3 are packaged with the Wise Installer. For Python 2.4, we have developed a packaging system based on Microsoft Installer.

In this paper, we explain how Installer differs from traditional packaging tools, such as Wise, and how we use Installer to provide Python packaging.

Lightweight SE methodologies have been acclaimed as efficient and humane alternatives to process-intensive software development--at least, for projects that are small enough and non-critical enough to warrant their use. This talk assesses a project that appeared to be a good fit for lightweight methods, but wasn't--thanks, in part, to the impact of Python's language model on code quality. Quality control problems were ultimately resolved using a far more deliberate approach to testing than the literature suggests--and two author-created, open-source libraries for streamlining program testing.

A new feature of doctest in Python 2.3 was support for creation of pyunit unit tests with doctest. Unit testing is an important practice for improving the quality of software and for enabling refactoring. The standard Python unit testing framework, pyunit was based on the existing Java unit testing framework, junit. The framework provides a testing applications-programming interface (API) through inheritance that supports test set up and that provides various ways of making assertions about tests. It's common for testing code to contain more testing API calls than application code. Descriptive text is provided as comments and is usually in short supply.

Doctest is a system for writing tests within Python documentation strings. The emphasis is on documentation. Tests are provided as example code, set off with Python prompts. Doctest tests lend themselves toward a literate form of test code.

In Python 2.3, a new feature was added to Python to create unit tests from doctest doc strings. The talk provides an overview of doctest, shows how to create unit tests with doctest, and compares and contrasts regular pyunit unit tests and doctest-based unit tests.

Epydoc is a tool for generating API documentation for Python modules, based on their docstrings. This API documentation provides a useful reference resource when working with unfamiliar modules or packages. Navigation tools such as a table-of-contents frame and an index allow the user to easily locate the object they're looking for. And object docstrings, along with Python's powerful inspection capabilities, allow epydoc to provide the user with useful information.

Epydoc can generate documentation in a wide variety of formats including HTML, plaintext, LaTeX, and PDF. The HTML and LaTeX output can be easily included as an appendix to a package or module's documentation.

Epydoc understands four different markup languages for docstrings: Epytext, a lightweight markup language with support for basic formatting constructs; ReStructuredText, an "easy-to-read, what-you-see-is-what-you-get plaintext markup syntax;" Javadoc, the standard markup language for documenting Java source; and plaintext. In the first three markup languages, special tags can be used to add information about specific fields, such as parameters or instance variables.

This presentation will consist of a tutorial on using Epydoc: how to navigate its output; how to run it (including both the command-line interface and the GUI); how to write docstrings in different markup languages; how to use special markup features, such as cross-references and field descriptions; and how to customize its output.

URL: http://epydoc.sourceforge.net

Thr proposal outlines a tutorial for programming with the GTK graphical toolkit and the Gnome desktop environment libraries. Topics such as getting started with GTK, user interface building with Glade, the correlation between the C and Python APIs, and using various Gnome technologies are covered. I will also use several "real world" examples from the open source world and also personal projects.

An important feature in an IDE (Integrated Development Environment) is support for code browsing, autocomplete and call tips (sometimes called intellisense). ActiveState's commercial Komodo IDE supports many languages -- mainly Python, Perl, PHP, Tcl, XML/XSLT and JavaScript. The engine for these features, therefore, has to be able to provide information in a language-neutral way.

This presentation will discuss the design and implementation of this code intelligence engine in Komodo (the frontend is written in Python). Particular attention will be paid to the Python backend over some of the other languages like Perl and PHP.

Circumstances exist where it is desirable to change the behavior of a running application without interrupting the service of those users whom it is currently serving. In high load environments, it is often the case that there will always be a significant number of users relying on the service. In these environments, the simplistic approach of waiting for all users to sign off, then shutting down and restarting the server software is not feasible.

Rather than discussing how to extend Python with C or C++ (which has been made even more popular by tools like SWIG, Boost.Python, SIP, etc.), the presentation describes the benefits and concerns of using Python as an extension language. The presentation also discusses Elmer; a tool that allows Python modules to be used seamlessly in C or Tcl projects. Elmer is effectively the opposite of tools like SWIG, and instead generates an interface to a Python module that is native to the host language which conceals all indications that the underlying module is written in Python. Elmer has been successfully used in both commercial and non-commercial applications where the benefits of Python were needed in systems written in less flexible languages, some of which with maintainers who had no knowledge of Python. (note: additional information about Elmer, including examples, can be found at elmer.sourceforge.net)

• Most Python developers are familiar with the benefits of using C/C++ for writing extensions, but what are the advantages of using Python as an extension language?
  • quickly prototype a new module
  • utilize Python's vast libraries
  • reuse code already written in Python
  • ...and all the other advantages of Python which may not be available in the host language: (object-oriented, byte-compiled, dynamically typed, platform-independent, easy to maintain, etc.)
• What things need to be considered when using Python as an extension language?
  • packaging ("frozen" or "warm")
  • linking in libpython and any other libraries / building a specialized libpython
  • initializing the embedded interpreter
  • type conversions
  • debugging
  • runtime speed / overhead
• What is elmer and how can it help me use Python to extend a system written in a different language?
  • what does elmer do and how is it different from other interface generators?
  • creating the elmer interface file
  • debugging a Python extension with elmer
  • demonstration of a C/C++ program with a Python extension
  • demonstration of a Tcl program with a Python extension

There are many ways to build Python modules wrapping C code but one of the most elegant is Pyrex. Pyrex introduces a complete abstraction layer that allows a Python programmer to write Python-like code that manipulates C types and can be compiled to C. This talk will describe how to manage the mapping between C types and Python types using Pyrex:

• referring to C types
• referring to C functions
• creating C types
• creating C functions
• inclusions
• debugging the generated code

Several options exist to create Python bindings for large C++ frameworks. The complexity and the fact that C++ can be difficult to integrate with itself let alone other languages makes it necessary to be aware of and understand certain pitfalls and constraints prior to attacking such a major task.

This paper describes an experimental embedding of Python into DrScheme for educational and professional use. The core of the system is a compiler, which translates Python programs into equivalent MzScheme programs, and a runtime system to model the Python environment. The system's C extension mechanism is nearly complete and source-compatible with CPython's system. The generated MzScheme code may be evaluated or used by DrScheme tools, giving Python programmers access to the DrScheme development suite while writing in their favorite language, and giving DrScheme programmers access to Python. Its development gives valuable insights into the kind of problems one faces when embedding a real-world language like Python in DrScheme. In addition to C extension compatibility, we are now also implementing code optimization.

IronPython is yet another implementation of the Python language that targets the Common Language Runtime (CLR) for the .net platform. It compiles Python programs into verifiable IL (CLR bytecodes) and then dynamically executes them. The early performance results show that Python can run fast on this platform.

Pyrex offers an amazing opportunity for the Python community to shake Python's reputation for being slow. With minimal changes most Python code can be compiled in Pyrex. This will not usually give much of a speedup but if the user starts to apply minimal effort to type declarations and so forth, they can quickly get within spitting distance of C. Heroic measures can then be applied to get performance essentially the same as C.

• What is Pyrex
• How does Pyrex improve the performance of your code?
• Real-world example: Bisection algorithm
  • I will walk through 4 optimization levels
• Real-world example: Expat XML Parser Binding
  • I will compare Python code to C code and do some benchmarking
• Benchmarking techniques
• Final considerations and summary

Pure Python code is slow, primarily due to the dynamic nature of the language. I have begun building a compiler to produce fast native code from Python source programs. While compilation can improve performance, any such gains will be modest unless the compiler can statically resolve most of the dynamism present in source programs.

If we can successfully perform static type inference on Python programs during compilation, then we can remove most type checks and most instances of dynamic dispatch and dynamic binding from the generated code. Removing dynamic dispatch and binding leads to large performance benefits since their existence precludes many traditional optimization techniques, such as inlining.

I have built a static type inferencer for Python called Starkiller. Given a Python source file, it can deduce the types of all expressions in the program without actually running it. Starkiller's primary goal is to take a Python source program as input and deduce the information needed to make native code compilation of that program easy. Most of this talk will focus on how Starkiller statically infers types and how the information it generates is used to direct compilation.

Pyrex compiles a very Python-like language to C. This allows easy integration of Python and C code and a highly producive environment for improving the performance of Python code. The only snag is that Pyrex does not apply many optimizations beyond those it is specifically directed to apply by the programmer. It does no analysis of the code to determine what sorts of performance-enhancing code transformations are possible.

This talk will discuss an experimental fork of Pyrex aimed at introducing some of these performance enhancements. In particular:

* constant interning

* compile-time function and method binding

* type-specific code generation

Many other potential (but unimplemented) optimization techniques are also available and will be discussed. Audience discussion will be encouraged.

The Pypy project (http://www.codespeak.net/pypy/) aims to reimplement Python in Python. After 10 months and 5 sprints we have an almost complete prototype that runs under the regular C Python interpreter. This makes it very slow and work is now focusing on code generation and optimisations that should bring it to the speed of normal Python and beyond. The implementation uses a novel way of separating the translator from something we call Object Spaces, that can be used for various purposes, like execution of code or the creation of an annotated control flow graph. We will give a status update for the project, an architecture overview, insight into some interesting implementation details and an introduction to how to participate in the project.

Web Services for Python is an open source project that brings many web services technologies to the Python community. Contained within the project are two implementations of a SOAP 1.1 compliant client and server, each containing WSDL comprehension capabilities. Using Web Services for Python, a Python developer can expose their functions via a SOAP interface. Similarly, a Python developer can bind to operations exposed via SOAP on a server, which may not necessarily be implemented in Python.

Zope 3 is a major rewrite of the Zope application server. The motivation and major features of Zope 3 will be presented, including an overview of the Zope component architecture. The plans for transitioning from Zope 2 to Zope 3 will be presented, including an overview of the upcoming Zope 2.8, Zope 2.9 and Zope X3 releases.

Note that unlike a normal paper presentation, it is less a presentation of specific work or ideas than a status and planning presentation. It is a bit like Guido's presentation that summarize the status and future of Python. It will provide an opportunity for people who follow Zope to find out what the future brings and how we plan to get there. Opportunity for questions, answers and discussion is an important aspect of this talk.

This tutorial would be an hour or so long, and would introduce basic usage of Quixote.

Topics covered (in roughly this order): installation; explaining object traversal; PTL syntax; automatic HTML escaping; the HTTPRequest and HTTPResponse classes; session tracking; running standalone HTTP servers with Medusa & Twisted; general application design patterns.

A crash course to using Mod_Python, focusing at web development aspects, rather than the low level Apache stuff.

This talk will handle new features of upcoming Mod_Python 3.1, which I am very certain will be relased as stable by the time PyCon happens.

Beginning with the intruduction to the Publisher handler, then PSP, then combination of Publisher/PSP this talk will present simplistic snippets of code demonstrating "Hello world!" level of usage. We will also cover the new Cookie and Session modules. There will be a few slides and time devoted to the rationale and history of each function from the author's perspective.

Time-permitting, it will also cover how to create a native mod_python handler.

Web interfaces are typically completely stateless. While this keeps the "Back" button useful, it limits the creativity with which web applications can be built.

The author last year developed an ASP (VBScript- based) prototype that allowed web pages to make use of other page functionality as necessary to collect required information. While the system gave a gratifying degree of code- reusability and allowed quite flexible application design, the host language's limitations made some tasks more difficult than necessary, and limited architectural flexibility.

The framework has now been implemented experimentally in the mod_python environment, with encouraging results. The most significant feature of the implementation is a "page stack" that allows pages to suspend their own activities, call another page, and then have that page reactivate the original URL after suitable changes to the session state, with additional arguments representing a type of "return value" being a common usage.

While there are clear parallels with a procedure call there are also significant differences due to the nature of HTTP interactions. A discussion will compare and contrast the two.

The principles of the system will be described alongside a brief demonstration of the original ASP system, which maintains a moderately complex (~45 tables) relational database. The Python implementation will be described, with examples to highlight different benefits of using such systems, including the additional flexibility of being able to store Python objects of arbitrary complexity in session state and the advantages of such systems in maintaining complex relational data structures.

Open Space discussions about possible open source development of this architecture will be encouraged.

This presentation describes the FormEncode (formencode.org) validation and form generation package. FormEncode is designed to be both complete in its role, while avoiding excessive frameworkification. It provides significant features not found in most form packages, but does not force the user/programmer to use a particular MVC model, configuration scheme, or generally adopt the original author's worldview.

Some of the features: validates rich structures (lists and dicts), both individual members and as a whole; loose coupling between validation, form generation, and domain objects; no static configuration; arbitrary nesting of structures and forms possible; framework neutral.

The presentation consists of a brief introduction (goals), and short examples used as a centerpoint for a discussion of the design choices.

See paper.

Panda3D or Platform Agnostic Networked Display Architecture is a powerful rendering engine for SGI, Linux, Sun, and Windows. It was originally developed by the Walt Disney Imagineering VR Studio and has been used for their massively multiplayer online game Toontown Online. It has since been generously made available to the open source community. The core of the engine is in C++. Panda3D/DIRECT provides a Python scripting interface and utility code. In this paper we present an overview of Panda3D technology for developing real time interactive games and VR experiences using Python scripting. We delineate the various tools and features of the engine. As case studies, we present student projects from the "Building Virtual Worlds" class taught at Carnegie Mellon's Entertainment Technology Center. In conclusion we discuss plans for future development of Panda3D.

Pivy is a Python binding for the popular object-oriented 3D C++ toolkit Open Inventor which presents a programming model based on a 3D scene database. We describe the benefits of using Python for Open Inventor programming.

In addition to the general benefits of using Python for Open Inventor development, the Scripting Node is one of the most prominent features of Pivy. The Scripting Node works similarly to the JavaScript facilities in VRML: small reusable applications can be developed by embedding Python code in Open Inventor files.

(focusing specifically on PostgreSQL, rather than a generic "how to use relational databases from Python", since there's such particularly interesting stuff that can done w/PG because of the embedded Python procedural language)

- using DB API for Python <-> PostgreSQL

- differences in database adapters for PostgreSQL

- using Python as a procedural language within PostgreSQL

- Different methods of connecting Zope & Plone to PostgreSQL (Ape, ZSQLMethods, Archetypes)

- PostgreSQL-specific performance tips for web applications and other Python access.

- Advanced techniques for having PostgreSQL notify Zope (& other web applications) when cached results should be cleared.

- Running Zope *within* PostgreSQL instance for fastest communication between processes.

* What is atop?

ATOP, the Atomic Transactional Object Persistor, is a Python object database implemented atop the 'bsddb' module, with functional similarities to other python packages such as ZODB and COG.

ATOP's design emphasizes good error reporting, simplicity, flexibility, and scalable design decisions.

We present an object oriented partial differential equation (PDE) solver written in Python based on a standard finite volume (FV) approach.

The solution of coupled sets of PDEs is ubiquitous in the numerical simulation of science problems. Numerous PDE solvers exist using a variety of languages and numerical approaches. Many are proprietary, expensive and difficult to customize. As a result, scientists spend considerable resources repeatedly developing limited tools for specific problems. Our approach, combining the FV method and Python, provides a tool that is extensible, powerful and freely available. A significant advantage to Python is the existing suite of tools for array calculations, sparse matrices and data representation.

Our framework includes terms for transient diffusion, convection and standard sources, enabling the solution of arbitrary combinations of coupled elliptic, hyperbolic and parabolic PDE's. Current models include phase field treatments of electrochemical, polycrystalline and dendritic phase transformations.

• Motivation
  • Existing approaches
  • Weaknesses of existing approaches
• Approach
  • Object relationships between variables, equations, terms, etc.
  • Python /is/ the input file
  • Leverage 3rd party numeric libraries
• Drawbacks
  • Efficiency
  • Complexity of installation
• Examples
  • Crystal Growth
  • Thermodynamics of Stressed Solids
  • Pneumonoultramicroscopicsilicovolcanoconiosis
  • Electrochemistry

Astronomers from around the world come to the Green Bank site of the National Radio Astronomy Observatory to perform radio astronomy observations with the Robert C. Byrd Green Bank Telescope. Thus, there is a pressing need for a generic data display and analysis toolkit that will provide radio astronomers with a versatile mechanism for viewing and interpreting their observation data. The reduction of observation data is an interactive, highly iterative process of viewing the data in detail, editing it (data flagging), and analyzing it (data fitting). Currently, there are no existing tools that accommodate data viewing, flagging, and fitting within the same application. There are good tools for producing publication quality plots, for producing interactive read-only plots, and for doing data analysis. However, no existing free tools solidly combine all these features, and no existing tools provide quality interactive graphical data editing. The creation of a single application that marries these needs is the motivation for Data Extraction and Analysis Program, or DEAP. Even though DEAP has been developed with the data reduction needs of the NRAO in mind, all assumptions regarding the nature of the data entered into the program were kept at a minimum meaning that DEAP is intended to be useful for viewing, flagging, and fitting many types of data, not just astronomical data.

Over the last 10 years I have developed software for structural biology, bioinformatics, and chemical informatics. At the beginning of that period most software for those fields was monolithic and driven by the command-line or perhaps an application specific programming language. There were very few libraries outside of numeric methods. In the early 1990s this started to change as people began to embed off-the-shelf languages like Tcl and develop sharable libraries for other high-level languages.

Biology sequence research has had a long history of information sharing and data management and was an early adopter of the web. Sequences are often treated as simple strings which makes perl a natural fit. It's no surprise then that bioperl started in the mid 1990s as the first distributed software community for this field. Biopython followed in 1999 and rather than duplicate resources we decided to join with bioperl. The result is the Open Bioinformatics Foundation, which also includes BioJava and BioRuby.

Perl is still the dominant high-level language in bioinformatics and that is unlikely to change soon. Structural biology and chemical informatics is a different matter. These require more complex data types than strings which are more cumbersome in Perl but a very natural fit for Python. Indeed, many of the large-scale structure visualization programs use Python and the two main commercial chemical informatics toolkits also have commercially supported Python bindings. On the downside the chemistry field is more proprietary than biology, in part because it's easier to make money from a drug than it is knowing that modifying a certain gene can cause a fruit fly to grow extra legs instead of wings and in part because chemistry research usually requires less teamwork. So while there have been some attempts to start a chemistry equivalent to the OBF they have yet to blossom.

In my talk I will describe some of the history of software development in the computational life sciences with an emphasis on how Python fits into the various subfields and how it's used in different companies. I will include pointers to many of the relevant Python-based projects and end with some thoughts on the future. Attendees will leave with an interesting and personal view of how scientific software development works and how the different life sciences projects are tied together, rather than an in-depth description of any one project. This talk will be targeted to software developers. A strong background in the sciences is not required.

In this presentation, we discuss the use of Python and SimPy to model the flow of material within a fuel fabrication facility. Early attempts at modeling the facility with a commercial simulation tool were abandoned because more flexibility in the implementation was needed than the tool could provide. Our customers are continually refining the design of the faciltiy and the model needs to respond quickly to these changes. A decision was made to implement the model using Python and SimPy to provide the necessary flexibility, with some lingering concerns over performance. This decision has turned into a boon for the project as the use of Python has facilitated the conceptual development of the model without creating unacceptable run times. SimPy has provided a clean and concise simulation framework that has almost no impact on the clarity of the model and adds little to the codebase. Tony Vignaux, one of the original authors of SimPy, has referred to the work as perhaps the first real-world application of SimPy.

• Introduction
  • What is a fuel fabrication facility?
  • Why are we modeling it?
  • More detailed description of facility operation
  • What our customer wants. Facility accounting and keep the IAEA happy
• Implementation Options
  • Commercial modeling tool. Aborted because of lack of flexibility and unclear model definition.
  • Python and SimPy. Flexible, clear and transparent model description, but what about performance?
• Python Model
  • Glovebox
  • Facility
• Use of SimPy
  • Gloveboxes are processes
  • Cleanups and inventory writes are also processes
  • Avoided the use of resources by having upstream gloveboxes automatically ship to downstream gloveboxes
• Results
  • Sample data
  • Performance (speed)
• Next Steps
  • Add measurements
  • Flexible sub-MBA structure

Computer programming contributes an essential aspect to a well-rounded computer literacy, analogous to the role of writing in the domain of traditional print literacy. Many computer languages are unwieldy for rapid prototyping; however, the open-source Python language was designed to be easy for beginners to learn and is appropriate as a first computer language. This presentation explores what considerations are most important in teaching Python as a first programming language in a secondary school setting.

The Python edu-sig newsgroup has been discussing issues associated with teaching and learning Python in secondary education classrooms for about four years. In the process of fulfilling the requirements of a PhD dissertation, I analyzed selected threads from those discussions to isolate the salient viewpoints of those issues.

Three major findings were derived from the results: a) computer programming is a bona fide form of writing that combines well-formed arguments with good stories, and is central to a complete mastery of computer literacy; b) learning to program enables programming to learn; that is, the major purpose of learning computer programming in school settings is to develop the means of using programming to promote learning in other subject areas; and c) computer programming fosters a variety of executable notations that alters what is worth knowing in other subject areas.

Guido van Robot, or GvR for short, is a new programming language intended for instructional purposes. It is written in Python, and aims to be a Pythonic improvement of Karel the Robot.

Yorktown high school teacher Jeffrey Elkner will demonstrate GvR and discuss its use in introducing his students to basic programming concepts.

A set of teaching lessons will then be compared in both their original Karel the Robot and GvR forms, demonstrating how the new Python-like syntax has made the problems shorter and easier to understand.

NLTK, the Natural Language Toolkit, is an open source Python package for symbolic and statistical natural language processing. NLTK is accompanied by extensive documentation, including tutorials that explain the underlying concepts behind the language processing tasks supported by the toolkit. It also includes graphical demonstration programs and sample corpora.

NLTK was originally developed as courseware for an introductory class in NLP (natural language processing). In addition, it is ideally suited to students who wish to independently learn about NLP; and to students who conduct research in NLP or closely related areas, including empirical linguistics, cognitive science, artificial intelligence, information retrieval, and machine learning. NLTK has been used successfully as a teaching tool, as an individual study tool, and as a platform for prototyping and building research systems.

For my presentation, I will introduce the Natural Language Toolkit, and demonstrate how it can be used as a pedagogical tool to add a practical programming component to an NLP class. I will discuss the criteria and requirements that should guide the development of a programming toolkit for courseware, and explain how those criteria affected the design and implementation of NLTK.

I will also argue that Python provides an ideal language for implementing programming toolkits for courseware. Its simple syntax and transparent semantics ensures to a shallow learning curve, and its large standard library provides a great deal of power when needed. Furthermore, Python code is extremely easy to read (it has been praised as "executable pseudocode"), ensuring that students can learn by looking at the courseware's source code, and not just by using it.

URL: <http://nltk.sourceforge.net>

A revamped mathematics curriculum might shift its emphasis from sophisticated calculators and computer algebra systems to doing more with an "implementation language" such as Python. What would such a revamped mathematics curriculum look like? I have some ideas about that.

One goal would be to provide some continuity with the past, so that much if not all of the content remains recognizable to long-time math teachers. Another goal would be to use object-oriented semantics to introduce new "math objects" such as rational numbers, polynomials, vectors, matrices, polyhedra.

Operator overloading (easy in Python) will make these objects more consistent with traditional notations, while giving students deeper insight into what goes on under the hood. Abstract algebra becomes more accessible using operator overloading, coupled with this appreciation of "math objects" as the generic elements of a group, ring or field.

This presentation will simulate a sequence of math courses, compressed into a short time, sampling source code, shell use, possible techniques and approaches. The rhetorical question here is: wouldn't mathematics be more interesting and clearly relevant to a larger audience, if at least some elements of this approach were more widely adopted? Of course the speaker's aim is to elicit an affirmative response.

PyGeo is a real-time dynamic 3d graphics applications, with high quality graphical output via VPython rendering. It should provide the means for a visually entertaining presentation.

The presentation would include a demonstration of PyGeo, and a discussion of its motivation, and of its design.

see:

http://pw1.netcom.com/~ajs

Summary Student Teacher Online Applications (STOA) is a web-based K-12 environment built on Zope/CMF, Python and MySQL. In its second year of deployment, STOA is now used by over 800 students, faculty and administrators to manage student schedules and class rosters, to report attendance, to post assignments, notes and handouts, to turn in work, and to write and print student progress reports. This case study will discuss the process of developing a Zope/CMF web application, along with the advantages and pitfalls of Zope/CMF we encountered in implementing STOA.

STOA was developed at Canterbury in response to the lack of viable other options. The school had deployed the Manhattan project for an academic year to generally positive reviews. However, when we attempted to address feature requests and improvements we found the code to be unwieldy to manage. Zope was selected for several reasons, including its Python roots. The case study will briefly discuss the options available and our reasoning for choosing Zope.

While both developers were extremely familiar with Python, Zope had a steep learning curve. Concepts such as aquisition, TALES and Python integration, and external procedures all took time to learn and understand. The case study will detail some of the central ideas we took away from the process so that new developers will have a brief introduction. After the first year of deployment several key components were extracted into a STOA Zope product which extends CMF types. The process of creating the product will be discussed, with specific attention paid to aspects not covered in the Zope/CMF documentation. Other items discussed will include the use of workflow and roles, scaling the application while adding services, and administrative issues. Finally, the issue of revision control and developer coordination in Zope will be discussed. After breaking the live instance one too many times, we tackled the issue of creating a staging server and development process. The details of this will be discussed.

STOA is presently a stable, successfully implemented Zope application. While STOA relates to a particular problem domain, the lessons learned from it's development apply to Zope and CMF in general.

The elspy package (elspy.sf.net) embeds a Python interpreter in the Exim mail server and uses it for filtering mail; this talk introduces it and shows how to write Python filtering rules. It would be a relatively short talk, at most 30 minutes long (and trimming it to be 20 or 25 minutes likely wouldn't be a problem.)

Topics covered: installing elspy; explanation of Exim's local_scan() function and how Python interfaces to it; what exceptions your Python local_scan() function can raise (RejectMessage, TempRejectMessage, AcceptMessage); some simple examples and comparison with the corresponding Exim filter rule; example showing how to block mail with executable attachments; possibly an example of interfacing with SpamBayes; comparison with sendmail's milter interface.

With Python, an ordinary PC can be transformed into a powerful tool for the development, testing, demonstration and deployment of embedded systems. All the required components -- such as Python itself, wxPython and PySerial -- are freely available and are cross-platform.

In an embedded project, Python is useful for tasks such as code generation, unit testing of embedded software components, and rapid prototyping of features.

Python can also be used to create a comfortable build environment for embedded systems. Using Python in this way makes it simpler to support different target platforms. With Python as the glue that coordinates the other tools in the environment, it is far easier to selectively replace those other tools when porting to a new target.

Building a sophisticated control console is readily accomplished using Python. Such a console, running on a standard laptop, creates a powerful troubleshooting facility that can be used in the field. The console can be readily internationalized, converting compact error codes sent by an embedded device into descriptive error messages in a variety of languages.

One very exciting application of Python to embedded systems is in the role of a device simulator. A simulator can act as a node in an embedded network, while displaying the internal system state via animated images on the screen. Simulators are very valuable during the early stages of an embedded project, when little actual hardware is available. By taking the place of missing devices, simulators can allow software development to continue even before the hardware design is completed.

**Demonstrations using actual hardware will be used to illustrate some of the points in the presentation. See the slightly longer summary in the proposal for more information.**

A common complaint made of Python is that it is "too slow" for serious application development, and is only suitable for "scripting" or "prototyping" tasks. The Shtoom application (http://shtoom.sf.net) is a Voice over IP (VoIP) software phone, implemented in Python using the Twisted framework. This paper will include a brief overview of SIP and RTP (the protocols underlying Voice over IP), examine some of the issues relating to the implementation of Shtoom (with a digression on issues relating to timing), and will hopefully help demonstrate why implementing applications in Python is perfectly feasible. There will hopefully also be time in the talk for some demonstrations of Shtoom.

A natural inclination when creating high-availability networks, especially those involving cryptographic operations, is to develop in a low-level "system" language. We will discuss the alleged trade-offs of this philosophy and present performance data to justify a C-extension module of core cryptographic services. The construction and integration of this module will be detailed. In closing, US Government standards for crypto certification will be presented in the context of obtaining certification for a Python module.

I wrote two programs to help with part of our recent kitchen remodeling: One program produced a full-scale drawing of part of our countertop, so that the fabricators had an accurate picture of its unusual shape; the other let us experiment with tile layouts for the wall behind the stove.

The ephemeral nature of these programs imposes different requirements on them from most development projects: Maintenance and reuse were completely irrelevant, but correctness and ease of construction were crucial.

I did not have to use Python for either of these programs, but chose to do so after thinking about all the alternatives. This talk will concentrate on what aspects of Python made it attractive for this purpose, and how I used these aspects to minimize the total effort. It will also include demonstrations of the programs and photos of the finished kitchen.

In this talk aimed at open source developers curious about business and business people curious about open source, I will present the history of how ActiveState and more recently Sophos have used open source software (including Python and many Python-related projects) in our software business, from internal systems to commercial products.

Drawing from our experience, I will distill lessons learned from our successes and failures, and point out simple things that commercial users of open source can do to help foster good relationships with their open source suppliers, as well as tips for open source project leaders who are eager to see either financial rewards or other involvement from industry in their projects.

• Introduction
  • business types eager to benefit from hot new trend
  • open source types need to pay the rent
  • users want more, better, faster, cheaper
• Brief ActiveState/Sophos history
• Understanding the motivations of the other
  • motivations of open source folks
  • motivations of business types
  • fears of open source folks
  • fears of business types
• Bad ideas
  • Forcing the other to do things your way
  • Showing disrespect for the other
• Good ideas
  • Identifying your strengths in the eye of the other
  • Being flexible
• Business risks of using open source
• Open source risks of working with business
• Business benefits of using open source
• Open source benefits of working with business