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. 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. Maybe this isn't an issue here. On Thu, 24 May 2001, Greg Stein wrote: [...] > 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? How stable? (in terms of interface; I'm assuming it doesn't crap out through bad programming or it'd be a non-starter) > 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. Cheers, M.
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