Guido van Rossum
guido at python.org
Sat Aug 18 04:35:37 CEST 2007
On 8/17/07, Talin <talin at acm.org> 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/)
More information about the Python-3000