Hey I agree we should standardize on a version of python. I would think 3.8 would be the best.

Just one thing to note, F-strings are actually a python 3.6 feature, so that shouldn't be something we need to worry about here. 

--Perry 

On Fri, Jul 3, 2020 at 4:39 AM Ondrej Lichtner <olichtne@redhat.com> wrote:
Hi all,

since we've moved to python3 that is actively developed and versions
move between various long term/short term support cycles, we should also
adapt LNST to this cycle of updating which minimal version of python
LNST requires.

TL;DR: The main questions I'm asking are:
* how do we _implement_ a python version requirement?
* how do we _upgrade_/_migrate_ in the future?
* how do we _document_ a python version requirement?
* which version do we want to use _now_?

More context:

I think at the moment we have a "soft" requirement for python3.6. Soft
because we:
* probably haven't tested on anything older
* it's not explicitly configured/documented anywhere

At the same time, there are now at least two reasons to start thinking
about moving to python3.8:

* I remember Perry asking about the f-string feature introduced in 3.8
* while working with Adrian on the TRex refactoring I started thinking
  about a feature for the lnst.Tests package that I've had in mind for a
  while, which requires a 3.7 feature
* python3.8 is the current version on Fedora32, is available in RHEL8
  (via dnf install python38), and python3.7 was skipped

The lnst.Tests feature I'm thinking of is "lazy" and "dynamic" loading
of BaseTestModule derived modules - for example at the moment, if a
Recipe imports any module from lnst.Tests (e.g. lnst.Tests.Ping), the
entire package is parsed and "loaded", which means that the python
environment will also parse and load lnst.Tests.TRex. This means that a
basic hello world recipe that simply calls Ping, will in some way
require load time dependencies of TRex.

The "lazy" and "dynamic" loading of test modules would ensure that when
a recipe calls:

    from lnst.Tests import Ping

Only the Ping module will be parsed, loaded and imported, and nothing
else. And the dynamicity here could mean that we could be able to extend
test modules exported by the lnst.Tests package via the lnst-ctl config
file, for example for user/tester implemented test modules that are not
tracked in the main lnst repository.

I wrote a rough patch to experiment with this:

---
diff --git a/lnst/Tests/__init__.py b/lnst/Tests/__init__.py
index f7c6c90..a39b6f4 100644
--- a/lnst/Tests/__init__.py
+++ b/lnst/Tests/__init__.py
@@ -12,8 +12,26 @@
 olichtne@redhat.com (Ondrej Lichtner)
  """

   -from lnst.Tests.Ping import Ping
   -from lnst.Tests.PacketAssert import PacketAssert
   -from lnst.Tests.Iperf import IperfClient, IperfServer
   +# from lnst.Tests.Ping import Ping
   +# from lnst.Tests.PacketAssert import PacketAssert
   +# from lnst.Tests.Iperf import IperfClient, IperfServer
   +import importlib
   +
   +lazy_load_modules = {
   +    "Ping": "lnst.Tests.Ping",
   +    "PacketAssert": "lnst.Tests.PacketAssert",
   +    "IperfClient": "lnst.Tests.Iperf",
   +    "IperfServer": "lnst.Tests.Iperf",
   +}
   +
   +
   +def __getattr__(name):
   +    if name not in lazy_load_modules:
   +        raise ImportError("Cannot import {}".format(name))
   +    mod = importlib.import_module(lazy_load_modules[name])
   +    globals()[name] = getattr(mod, name)
   +    return globals()[name]
   +
   +
   +# #TODO add support for test classes from lnst-ctl.conf

    -#TODO add support for test classes from lnst-ctl.conf
---

However this requires the ability to define __getattr__ for a module,
which is introduced as a python3.7 feature via PEP562 [0].

-Ondrej

[0] https://www.python.org/dev/peps/pep-0562/
_______________________________________________
LNST-developers mailing list -- lnst-developers@lists.fedorahosted.org
To unsubscribe send an email to lnst-developers-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/lnst-developers@lists.fedorahosted.org