On Mon, Mar 23, 2015 at 09:05:20PM +0000, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> > Many POSIX functions aren’t available on every system, especially embedded ones.
> 
> What do you call "embedded systems"? I worked on set top boxes (the box to watch television) between 2011 and 2013 and we had a regular Linux kernel with all POSIX functions. Most of the time, the CPU was a slow MIPS. The tool chain was based on GCC. For some hardware, we used the µlibc but this C library provides all functions required by Python.

My target platforms have been the Newlib-based Wii and 3DS homebrew toolchains, which emulate a POSIX system on top of the raw hardware (or in the case of the 3DS, a proprietary micro-kernel.

> 
> > Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.
> 
> I agree. Anyway, in the embedded world, softwares are usually old and heavily patched. For example, in 2013 we still used Python 2.5.2 with a lot of patches. For example, patches for cross compilation. But also backported features like HTTP Keep-Alive or HTTPS checks.

There is a port of Python 2.5.something for the Wii, terribly outdated, and this is why I wanted to merge the non-specifics parts of my port upstream, as I thought it would help everyone in that case.

> 
> Technically, you can easily fork Python repository and keep your patches up to date using rebase.
> 
> We defined better rules to support officially a platform. A requirement is for example to have a buildbot running tests daily on the platform. I'm not sure that you are able to host a public buildbot for each custom embedded platform...

I can provide such a buildbot on my spare Wii.  Not really for the 3DS yet, as the homebrew scene is much younger there and unrecoverable lockups happen.

> 
> Android looks a more important target and it was already discussed to setup a Android buildbot.
> 
> I'm in favor of *dropping* all these annoying #ifdef because it's harder to review, maintain and debug such code. Here is my contribution: issue #23753 "Drop HAVE_FSTAT: require fstat() to compile/use Python". A concrete example: we are working on a Python implementation of io.FileIO and I don't want to see hasattr(os, 'fstat') in the Python code because it has a performance cost *at runtime* (see issue #21859).

On those two platforms, fstat() is correctly defined and works fine, so it shouldn’t be a problem to drop its #ifdef.

> 
> See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes:
> https://mail.python.org/mailman/listinfo/mobile-sig
> 
> ----------
> nosy: +haypo
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22623>
> _______________________________________