On 8/17/07, Talin <[EMAIL PROTECTED]> wrote: > I wonder how hard it would be - and how much it would distort the Python > code base - if most if not all platform-specific differences could be > externalized from the core Python source code. Ideally, a platform > wishing to support Python shouldn't have to be part of the core Python > distribution, and a "port" of Python should consist of the concatenation > of two packages, the universal Python sources, and a set of > platform-specific adapters, which may or may not be hosted on the main > Python site.
Go read the source code and look for #ifdefs. They are all over the place and for all sorts of reasons. It would be nice if there was a limited number of established platform dependent APIs, like "open", "read", "write" etc. But those rarely are the problem. The real platform differences are things like which pre-release version of pthreads they support, what the symbol is you have to #define to get the BSD extensions added to the header files, whether there's a bug in their va_args implementation (and which bug it is), what the header file name is to get the ANSI C-compatible C signal definitions, what the error code is for interrupted I/O, whether I/O is interruptable at all, etc., etc. Don't forget that the POSIX and C standards *require* #ifdefs for many features that are optional or that have different possible semantics. Just read through fileobject.c or import.c or posixmodule.c. Sure, there are *some* situations where this approach could clarify some code a bit. But *most* places are too ad-hoc to define an interface -- having three lines of random code in a different file instead of inside an #ifdef doesn't really have any benefits. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
