[Python-Dev] APR (was: IPv6) (original) (raw)

Greg Stein gstein@lyra.org
Thu, 24 May 2001 06:59:21 -0700

On Thu, May 24, 2001 at 02:02:34PM +0100, Michael Hudson wrote:

I can't think of a good way of expressing this, but I don't think we should try to make writing non cross-platform code in Python impossible.

I don't think this would preclude writing non cross-platform code. As I mentioned, there isn't anything that would prevent the stuff from working side by side.

The idea is to simplify certain aspects of Python's platform specific stuff. For example: all those variants of dynamically loading shared modules (Python/dynload_*.c) can be tossed along with the config magic.

Yes, it should be easy to write x-platform code, but if there's some very specific platform trick I can do with, say, setsockopt, I don't want Python to hide it from me just 'cause it doesn't work on VMS.

APR isn't a least common denominator approach.

... > 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.

How big is APR?

That's relative :-) On my Linux box, a stripped library is 85k.

It is also (theoretically) possible to skip building portions of APR. The APIs and symbols are set up for that, but the autoconf setup isn't yet. If you're embedding a private APR build, then you can fine tune what is needed. However, if you're building a public/shared one, then you wouldn't really want to trim it back like that.

How stable?

The existing functionality is quite stable. We just keep adding more, though :-)

(in terms of interface; I'm assuming it doesn't crap out through bad programming or it'd be a non-starter)

hehe... you can call it a non-starter, then. APR assumes you pass it valid pointers and objects. For example, if you call apr_file_read(NULL, NULL, 100), then you'll get a segfault rather than EINVAL. Personally, I find that behavior quite fine (EINVAL will invariably get ignored; a segfault doesn't; and this is a programmer error that needs to be attended to -- throw it in his face)

Whether others think that is a non-starter... hard to know :-)

[ actually, one of the hardest things to integrate would be APR's memory management approach with Python's ]

> And note that some of those topics have some nice depth. As I mentioned, > networkio supports IPv6, but also portable name lookups, sendfile(), etc. > The fileio 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.

That's still less than Python isn't it? RiscOS, Amiga, PalmOS, VMS, Playstation 2(!), from looking at http://www.python.org/download/downloadother.html.

Sure it's smaller.

It's a blue sky radical suggestion. No more, no less. :-) I mentioned it because the IPv6 stuff came up. I already know a codebase that has handled all the portability issues. That is a bonus :-)

However, for the platforms that APR does handle today, that would still be a big code reduction for Python. And in the future? Why not extend APR to those other platforms and reduce the Python code even more.

I think shifting Python to a portability library is actually quite an interesting thought experiment. Enough to mention it and get people thinking. I think it could be quite handy for the longer term maintainability.

Cheers, -g

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