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