> Python does not yet have a robust ftp interface like Emacs' ange-ftp nor
> does it have an advanced desk top calculator like Emacs's calc. However
> it does have STDWIN, an easy-to-use windowing system.
You have not seen ftplib.py then... Very simple to use and fairly complete.
Also, the 0.9.9 version not only will work with STDWIN but also comes
with full support for X11R4/Motif.
> %%% 2. \part {Power} %%%
> %%% 2.1.3. \section {Python} %%%
>
> \section {Python}
> \begin{enumerate}
> \item
> ?? -- Multimedia interface.
> \item
> ?? -- Remote Procedure Call debugger
> \item
> texfix -- Crude convert latex to texinfo
> \item
> throughput -- measure tcp throughput
> \item
> dutree -- format du(1) output at a tree sorted by size
> \item
> findlinks -- recursively find links to a given path prefix
> \item
> lpwatch -- watch BSD line printer queues
> \item
> suff -- sort a list of files by suffix
> \end{enumerate}
rsa encryption, www, nntpxmit.py (nntpxmit replacement), and
I am sure many more.. I am currently writting a multi-line UNIX BBS
that is written in Python.
> %%% 2.2. \chapter {Graphics} %%%
> \section{Python}
> Through the use of the STDWIN paradigm, the same source code
> can do graphics in the following systems:
>
> \begin{enumerate}
> \item
> X-windows
> \item
> Macintosh using either Think C 4.02 or MPW C 2.02
> \item
> Atari ST
> \item
> DOS
> \item
> Silicon Graphics SGI workstations
> \end{enumerate}
>
> This approach allows flexibility but means that no one graphics system's
> potential is maximized.
the 0.9.9 version also have full X11R4/Motif support...
> %%% 2.3. \chapter {User Interface Building} %%%
> \section{Python}
> Through the use of the STDWIN paradigm, the same source code
> can do graphics in the following systems:
>
> \begin{enumerate}
> \item
> X-windows
> \item
> Macintosh using either Think C 4.02 or MPW C 2.02
> \item
> Atari ST
> \item
> DOS
> \item
> Silicon Graphics SGI workstations
> \end{enumerate}
>
> This approach allows flexibility but means that no one graphics system's
> potential is maximized.
see section 2.2
> %%% 2.4. \chapter {String Handling} %%%
> \section{Python}
> It has a string module and regexp module. It has all the string
> @emph{search} capabilities of Emacs, but since strings are immutable in
> Python, it understandably does not have Emacs Lisp's string replace power.
>
> \section{Tcl}
> Everything in Tcl is a string. It is very easy to map certain
> string-intensive applications to Tcl. For example, I wrote a program to
> do parallel library database searches in Tcl in about two weeks. Ranking
> the 4 languages in terms of how easy it would have been: Tcl, Python,
> Emacs, and I cant say about Perl because I gave up on Perl quickly after
> buying the book and seeing all those registers and the confusing
> context-intensive syntax.
did you try to code your program in Python? or as you just assuming
that Tcl would have been easier?
> %%% 2.5. \chapter {Process Control} %%%
> \section{Python}
> You would use pipes to do this in Python.
This is not 100% true! You also have the full C library of routines..
fork(), waitpid(), wait(), system(), pipes, kill(), etc..
they are all in the os and posix modules...
> %%% 2.6. \chapter {Sample Programs} %%%
\section{Python}
\begin{verbatim}
#! /usr/local/bin/python
import posix
print 'There are ', `len(posix.listdir('.'))`, 'files in this directory'
\end{verbatim}
> \item
> A lengthy file has been entered with records of the form:
> \begin{verbatim}
> <\n>NAME<\n>ADDRESS<\n>PHONE<\n>----------
> \end{verbatim}
> where \begin{verbatim}<\n>\end{verbatim} represents a line feed and the
> \begin{verbatim}----------- \end{verbatim} is used to
> separate records. Convert all entries in the file to a new format of
> the form:
> \begin{verbatim}<\n>NAME::ADDRESS::PHONE}
> \end{verbatim}
\section{Python}
\begin{verbatim}
#! /usr/local/bin/python
import strop
fp = open('testFile','r')
lines = fp.readlines() # read all lines in and seperate on \n's
fp.close()
fp = open('testFile','w')
for indx in range(0,len(lines)-4,4):
fp.write('\n'+lines[indx]+'::'+linex[indx+1]+'::'+lines[indx+2])
fp.close()
\end{verbatim}
> %%% 4. \part {Ease of Use} %%%
> %%% 4.1. \chapter {Documentation/Support} %%%
> \section{Python}
> Good. Covers everything but how to extend Python through C.
Incorrect. Look at python/misc/EXTENDING
> \chapter{Program Development}
>
> \section{Python}
> Good. The concept of immutable strings takes some getting used to.
The language is VERY regular and very powerful. You have seperate
name spaces that allow reuse and an OO design of your applications/scripts.
There are HUNDREDS of support modules you can import...
> %%% 4.2. \chapter {Extensibility} %%%
>
> When I say extensibility I mean the ability to add a new keyword or data
> type to a language as opposed to adding a new utility.
>
> \section{Python}
> Its possible in C. How to do it in C is not well documented.
It is very easy to add new types (I have added about 20 new types of
objects to Python both at the C code level as well as in Python code)!
--Lance Ellinghouse lance@markv.com
1231 bit key fingerprint = 56 DA 31 0C 17 51 36 6A 4E D4 E0 11 D9 B8 06 0A 1024 bit key fingerprint = 66 2C 75 F2 E9 1C 32 84 3A E3 B0 5E 48 01 4C 37 You can receive my Public Key by `finger lance@markv.com`