[Python-Dev] Python for Windows CE

"Martin v. Löwis" martin at v.loewis.de
Wed May 3 23:03:27 CEST 2006


Luke Dunstan wrote:
> 1. Is there any reason in principle why patches for Windows CE support would 
> be rejected?

No, not in principle. Of course,
- the patch shouldn't break anything
- you should state an explicit commitment to support the port for
  some years (or else it might get removed at the slightest problem)

> 2. Should I submit unified diffs or context diffs?

Yes, please :-) Actually, unified diffs are common these days,
in particular as subversion generates them.

> 3. The page http://www.python.org/dev/patches/style/ says that 
> platform-specific code should use preprocessor symbols documented for the 
> compiler, but existing Python code uses e.g. the invented MS_WIN32 symbol 
> instead of the standard _WIN32. Should we create a symbol MS_WINCE for 
> consistency or use the more common _WIN32_WCE?

Depends on who defines it. If the compiler defines it on its own, it is
best to use that. If some header file that gets unconditionally included
defines it, that is just as well.

If you explicitly define something, try to follow the conventions you
like best.

> 4. The latest existing patch set uses os.name = "ce", and this can be used 
> to distinguish Windows CE from other operating systems in Python code. The 
> existing patches also set sys.platform = "Pocket PC", but I am not so keen 
> on keeping this, mainly because Windows CE is equivalent to Win32 in many 
> cases. Any comments?

I would guide the decision based on the number of API changes you need
to make to the standard library (e.g. distutils). In any case, the
platform module should be able to reliably report the specific system
(including the specific processor architecture).

> (b) Instead we could use #ifdef HAVE_DIRECT_H, requiring patches to #define 
> HAVE_DIRECT_H for other platforms

That would be best. Python generally uses autoconf methodology, which
implies that conditionally-existing headers should be detected using
HAVE_*_H.

Regards,
Martin



More information about the Python-Dev mailing list