[Python-Dev] APR (was: IPv6)

[Greg Stein]

On Thu, May 24, 2001 at 02:22:42PM +0200, M.-A. Lemburg wrote:
> "Barry A. Warsaw" wrote:
> > >>>>> "GS" == Greg Stein <gstein@lyra.org> writes:
> > 
> >     GS>   Toss out a ton of the platform-specific stuff in Python and
> >     GS> use the Apache Portable Runtime (APR). It has IPv6 in it, but
> >     GS> it could also help with loading shared libraries, threading,
> >     GS> mmap'd files, sockets, etc.
> > 
> > I don't know squat about APR, but would it have to be either-or?  IOW,
> > would it be possible to wrap the APR in a module (or package) and
> > provide it as an importable alternative?

Sure, that is a possibility, but it doesn't save Python much in terms of
maintenance or portability. "Just another library"

Truly using it could certainly be done as a slow migration, and it is
definitely possible to only use portions, subsets, etc. Another alternative
would be to use APR as a "platform target". But that just adds yet another
platform to support rather than simplifying.

> Should be possible; the problem is: how do you get the APR types
> to interact with the original Python ones (e.g. file types). Many

The header is a total misnomer, but "apr_portable.h" provides access to an
opaque type's underlying native object (many of us aren't sure how Ryan
arrived at "portable" being the name for the least-portable aspect of the
library :-). Anyways... you can extract a file descriptor from a file or
socket or pipe. Or a thread ID from an thread object. etc.

> low-level Python functions require the native Python types, so
> while wrapping APR as Python module would provide an alternative, that
> alternative will most probably not help much w/r to simplifying
> portability issues.

Right. I'd say use the APR functions unless absolute speed is required (such
as the readlines stuff). But you could also argue that the hard-core
platform specific optimizations could go into APR itself, so that Python
doesn't have to worry about them.

> FYI, here's what the APR has to offer (taken from the APRDesign
> file that comes with Apache 2.0 beta):
> """
> The base types in APR
> file_io     File I/O, including pipes
> lib         A portable library originally used in Apache.  This contains
>             memory management, tables, and arrays.
> locks       Mutex and reader/writer locks
> misc        Any APR type which doesn't have any other place to belong
> network_io  Network I/O
> shmem       Shared Memory (Not currently implemented)   
> signal      Asynchronous Signals
> threadproc  Threads and Processes
> time        Time 
> """

That doc is out of date; the list is missing: shared library handling, i18n,
mmap, user information access (e.g. getpwnam), uuid handling, getopt
replacements, cryptographic random data, and a few other bits here and
there. The shared mem actually is implemented mostly, via the libmm library.

And note that some of those topics have some nice depth. As I mentioned,
network_io supports IPv6, but also portable name lookups, sendfile(), etc.
The file_io stuff support optimized stat() and opendir-type calls for the
platform.

> It currently supports: Unix (includes BeOS), Win32 and OS/2.

A lot more than that :-)  Pretty much all the Unix variants, including
OS/390 and BS2000 and MacOS X, and TPF, and some other oddballs. 

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/