Link Mauve added the comment: 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 <rep...@bugs.python.org> > <http://bugs.python.org/issue22623> > _______________________________________ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22623> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
