Python Programming

Osh (Object SHell) is a tool that integrates the processing of structured data, database access, and remote access to a cluster of nodes. These capabilities are made available through a command-line interface (CLI) and a Python application programming interface (API). Osh processes streams of Python objects using simple commands. Complex data processing is achieved by command sequences in which the output from one command is passed to the input of the next. This is similar to composing Unix commands using pipes. However, Unix commands pass strings from one command to the next, and the commands (grep, awk, sed, etc.) are heavily string-oriented. Osh commands send primitive Python types such as strings and numbers; composite types such as tuples, lists and maps; objects representing files, dates and times; or even user-defined objects.

Epydoc is a tool for generating API documentation for Python modules, based on their docstrings. For an example of epydoc's output, see the API documentation for epydoc itself (html, pdf). A lightweight markup language called epytext can be used to format docstrings, and to add information about specific fields, such as parameters and instance variables. Epydoc also understands docstrings written in reStructuredText, Javadoc, and plaintext. For a more extensive example of epydoc's output, see the API documentation for Python 2.5.

I hope this article encourages you to think about your command line programs in a different light, and to treat them as first class objects. Using inheritance to share code is so common in other areas of development that it is hardly given a second thought in most cases. As has been shown with the SQLiteAppBase programs, the same technique can be just as powerful when applied to building command line programs, saving development time and testing effort as a result. CommandLineApp has been used as the foundation for dozens of types of programs, and could be just what you need the next time you have to write a new command line program.

I'm declaring this one to be the winner! (Not that my opinion counts for anythin, but I'm just impressed: a1, b1 = zip(*ab) (or a1, b1 = apply(zip,ab)?) BTW: this process isn't 100% inverse. It has the side effect of turning lists or strings (non-tuple sequences) into tuples, if they are supplied as the original sequences.

On Mon, May 5, 2008 at 8:22 PM, Reckoner <recko...@gmail.com> wrote: > is there a unit step (heaviside) function in sympy? > I need to work a conditional into a symbolic expression. We have sign which is basically the same thing:

Pyspread is a spreadsheet that accepts a pure python expression in each cell. Requires Python 2.4, Numpy 1.0.4, and wxPython 2.8.7.1.

I didn’t want to make a new build tool. Honestly. The main reason that I created Paver is...

One of the main difficulties I've had using parser generators has been the difficulty of figuring out why a grammar didn't work. Fixing shift-reduce and reduce-reduce conflicts seemed like voodoo to me, and though I slightly understand better how to fix such things now it's still a different mode of thinking that I don't want to try to get into when I just want to parse something simple. PyMeta uses a variation on the Parsing Expression Grammar (PEG) approach to parsing. The chief consequence of this is there's no possibility of ambiguity in a parse: a successful parse will yield exactly one result, and you can trace the control flow through the grammar to figure out how it got there.

Python in Maya Done RightPymel makes python scripting with Maya work the way it should. Maya's command module is a direct translation of mel commands into python commands. The result is a very awkward and unpythonic syntax which does not take advantage of python's strengths -- particulary, a flexible, object-oriented design. Pymel builds on the cmds module by organizing many of its commands into a class hierarchy, and by customizing them to operate in a more succinct and intuitive way. Powerful new classes