[GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Markus Metz]

Just for clarification,

C code written for an older C standard works fine with newer C standards.

This is different with Python: code written for a previous Python version
might no longer work with a newer Python version.

Increasing the C standard for existing GRASS C code is safe, it will still
compile and work.

Increasing the Python version is not safe because existing GRASS Python
code might not be compatible with newer Python versions, thus the need for
a minimum required Python version.

Markus M

On Sun, Feb 7, 2021 at 10:36 PM Markus Metz <markus.metz.giswork at gmail.com>
wrote:
>
>
>
> On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert <
mlennert at club.worldonline.be> wrote:
> >
> >
> >
> > Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" <
kratochanna at gmail.com>:
> > >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová <kratochanna at gmail.com>
wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson <n_larsson at yahoo.com>
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> > >>> kratochanna at gmail.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <
> > >>> grass-dev at lists.osgeo.org> wrote:
> > >>> > Dear Devs!
> > >>> >
> > >>> > As a relatively new member of the GRASS GIS dev community, I have
had
> > >>> to search for information on mailing lists, old trac comments etc.
> > >>> regarding coding practice and in particular minimum programming
language
> > >>> standard support. Ending up in not entirely conclusive
understanding. Up
> > >>> until now, I have been mostly involved in Python development and
I’m still
> > >>> not absolutely certain, although I assume 3.5 is minimum version.
And I’m
> > >>> not alone, see e.g. [1].
> > >>> >
> > >>> > Now, I’ve encountered a similar dilemma with C standard support,
> > >>> attempting to address compiler warnings [2], in particular with the
PR
> > >>> #1256 [3].
> > >>> >
> > >>> > I would be great if there were a (one) place where the min
support of
> > >>> Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11,
C++14 …)
> > >>> standard is stated -- loud and clear. Obviously, there has to be a
> > >>> consensus in the community on these matters for that to happen.
Such a
> > >>> statement will also have to be revised now and then. (A related
question is
> > >>> also whether or not to support 32 bit, which I know have been raised
> > >>> recently).
> > >>> >
> > >>> > I’d appreciate your opinion is on this issue!
> > >>> > Let me put up a a suggestion for min. req. for coming GRASS GIS 8
as a
> > >>> starting point of discussion:
> > >>> > - Python 3.7
> > >>> > - C11
> > >>> > - C++11
> > >>> >
> > >>> >
> > >>> > Best regards,
> > >>> > Nicklas
> > >>> >
> > >>>
> > >>> Regarding Python, not sure if we shouldn't set 3.6 as minimum for
G8, it
> > >>> is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum,
some
> > >>> specific features we would want to use?
> > >>>
> > >>> Anna
> > >>>
> > >>> >
> > >>> >
> > >>> > [1] https://github.com/OSGeo/grass/issues/1241
> > >>> > [2] https://github.com/OSGeo/grass/issues/1247
> > >>> > [3] https://github.com/OSGeo/grass/pull/1256
> > >>> >
> > >>> > _______________________________________________
> > >>> > grass-dev mailing list
> > >>> > grass-dev at lists.osgeo.org
> > >>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> Well, I don’t have a very strong opinion regarding 3.7, but
personally
> > >>> I’d say 3.6 is an absolute minimum. I presume, for example, most of
us
> > >>> would prefer to use f-strings for string formatting.
> > >>>
> > >>
> > >> yes, f-strings are nice although they have limitations for using with
> > >> translatable strings (Vashek can expand on that)
> > >>
> > >>>
> > >>>
> > >>> On the other hand, 3.6 will reach end-of-support at the end of this
year
> > >>> right after its 5th birthday party and the support for data classes
in 3.7
> > >>> may potentially offer intriguing applications in G8.
> > >>>
> > >>
> > >> I noticed the data classes as well. Given 3.6 is reaching
end-of-support
> > >> soon, I agree with 3.7 for G8. I assume grass would be compatible
with 3.6
> > >> for a while anyway.
> > >>
> > >>
> > >>> Ubuntu 18 has Python 3.6 and Debian 9 has Python 3.5! What will
make the
> > >>> lowest common denominator? Debian 10 and Ubuntu 20 actually
supports Python
> > >>> 3.7 and 3.8 respectively. Forgive me if I’m ignorant, but isn’t it
possible
> > >>> to upgrade Python version on Ubuntu? Or is it just a pain with
package
> > >>> dependencies? Relying on default Python has never/rarely been a
luxury for
> > >>> other platforms.
> > >>>
> > >>> That being said, I think the most important part of this is that the
> > >>> community make a clear decision on min. supported Python version.
> > >>>
> > >>
> > >This GDAL's RFC [1] is helpful in summarizing the issue with Python.
> > >Looking more into this, I suggest to go have a longer term strategy for
> > >dropping support for Python versions, which would be relatively simple.
> > >Basically we would keep the lowest Python version that wouldn't reach
end
> > >of life at the time of a major release of GRASS. E.g. when we release
G8
> > >this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec
2021,
> > >we could drop 3.6 support next year. I am not saying we need to be
strict
> > >about that, but might be helpful as a guidance, and it is independent
on
> > >distributions (which is probably both advantage and disadvantage). I am
> > >unsure how this decision impacts packaging of grass, i.e. once we set
3.7
> > >as minimum, would maintainers need to make that Python a dependency of
> > >GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we
need
> > >to reevaluate that with each new major GRASS version. I think this is
> > >conservative enough and perhaps more in line with the C standards
> > >discussion.
> > >
> >
> > +1
> >
> > Moritz
>
> +1
>
> Markus M
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210209/02f1a503/attachment-0001.html>