On Wed, Jul 18, 2018 at 5:29 PM, Matthias Klose <d...@ubuntu.com> wrote:
> On 18.07.2018 14:49, Joel Sherrill wrote: > > On Wed, Jul 18, 2018, 7:15 AM Jonathan Wakely <jwakely....@gmail.com> > wrote: > > > >> On Wed, 18 Jul 2018 at 13:06, Eric S. Raymond wrote: > >>> > >>> Jonathan Wakely <jwakely....@gmail.com>: > >>>> On Wed, 18 Jul 2018 at 11:56, David Malcolm wrote: > >>>>> Python 2.6 onwards is broadly compatible with Python 3.*. and is > >> about > >>>>> to be 10 years old. (IIRC it was the system python implementation in > >>>>> RHEL 6). > >>>> > >>>> It is indeed. Without some regular testing with Python 2.6 it could be > >>>> easy to introduce code that doesn't actually work on that old version. > >>>> I did that recently, see PR 86112. > >>>> > >>>> This isn't an objection to using Python (I like it, and anyway I don't > >>>> touch the parts of GCC that you're talking about using it for). Just a > >>>> caution that trying to restrict yourself to a portable subset isn't > >>>> always easy for casual users of a language (also a problem with C++98 > >>>> vs C++11 vs C++14 as I'm sure many GCC devs are aware). > >>> > >>> It's not very difficult to write "polyglot" Python that is indifferent > >>> to which version it runs under. I had to solve this problem for > >>> reposurgeon; techniques documented here... > >> > >> I don't see any mention of avoiding dict comprehensions (not supported > >> until 2.7, so unusable on RHEL6/CentOS6 and SLES 11). > >> > >> I maintain it's easy to unwittingly use a feature (such as dict > >> comprehensions) which works fine on your machine, but aren't supported > >> by all versions you intend to support. Regular testing with the oldest > >> version is needed to prevent that (which was the point I was making). > >> > > > > I think the RTEMS Community may be a good precedence here. RTEMS is > always > > cross compiled and we are as host agnostic as possible. We use as close > to > > the latest release of GCC, binutils, gdb, and newlib as possible. Our > host > > side tools are in a combination of Python and C++. We use Sphinx for > > documentation. > > > > We are careful to use the Python on RHEL 6 as a baseline. You can build > an > > RTEMS environment there. But at least one of the Sphinx pieces requires a > > Python of at least RHEL 7 vintage. > > > > We have a lot of what I will politely call institutional and large > > organization users who have to adhere to strict IT policies. I think > RHEL 7 > > is common but can't swear there is no RHEL 6 out there and because of > that, > > we set the Python 2.x as a minimum. > > > > Yes these are old. And for native new distribution use, it doesn't > matter. > > But for cross and local upgrades, old distributions matter. Particularly > > those targeting enterprise users. And those are glacially slow. > > > > As an aside, it was not being able to build the RTEMS documentation that > > pushed me off RHEL 6 as my primary personal environment last year. I > wanted > > to be using the oldest distribution I thought was in use in our > community. > > doesn't RHEL 6 has overlays for that very reason to install a newer > Python3? > EPEL provides python 3.4 for RHEL6. (EPEL is a non-official add-on repository, but I suspect the vast majority who aren't running some single-task server have it enabled) Don't know if there's something equivalent for SLES. > Please don't start with Python2 anymore. It's discontinued in less than two > years and then you'll have distributions not having Python2 anymore. +1 -- Janne Blomqvist
