On 14May2014 14:45, Brett Cannon <bcannon@gmail.com> wrote:
On Wed May 14 2014 at 10:43:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 14 May 2014 14:20:26 +0000 Brett Cannon <bcannon@gmail.com> 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 ( http://legacy.python.org/dev/peps/pep-0011/ 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 limitation.
(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 <cs@zip.com.au>