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> > _______________________________________