[Python-Dev] APR (was: IPv6)

[Greg Stein]

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,
> > 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.
> 
> That's still less than Python isn't it?  RiscOS, Amiga, PalmOS, VMS,
> Playstation 2(!), from looking at
> http://www.python.org/download/download_other.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/