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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4