Main problem with rare platform support is not breaking it accidentally, since without buildbots we won't know when it's broken. This is why we don't make any promises.

On May 14, 2014 9:02 PM, "Cameron Simpson" <> wrote:
On 14May2014 14:45, Brett Cannon <> wrote:
On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou <>
On Wed, 14 May 2014 14:20:26 +0000
Brett Cannon <> wrote:
> Over the past week or so there have been 2 patches to add support for
> various UNIX OSs. Now I thought we had stopped trying to add new esoteric
> OSs (e.g. I had never heard of MirOS until the patch for it came in),
but I
> can't find a PEP that spells out what it takes to get a platform
supported (
> is about removing platforms,
> not keeping them or adding them unless you are re-adding one which
> apparently just takes a volunteer).

OTOH you can fix a platform bug without officially supporting it. If
someone files an OpenBSD-specific patch, it may make sense to commit it
even without officially supporting OpenBSD. In practice it all depends
on how intrusive / reasonable the patch is, and whether it is working
around a platform-specific bug rather than a standards-compliant

(we could call those "stochastically supported platforms" :-))

Very true, but these patches are all for e.g. configure to recognize a
specific platform by listing them in some constant. Changing code to be
more general I have no issue with since that's just good practice.

Recognition of a special platform isn't "full support", just addition of recognition making possible partial support for special cases. Unless that makes for some horrendous recognition decision tree somewhere I would have thought that's a pretty low bar to accept, and worth doing.

Leaving aside any bug actually fixed, it makes it much easier for someone else to fix a platform specific bug by making a test constant available for turning on whatever special mode/code is wanted.

More context on the example patch that triggered this query?

Just 2c,
Cameron Simpson <>
Python-Dev mailing list