Skip to content
This repository was archived by the owner on Jan 15, 2026. It is now read-only.
This repository was archived by the owner on Jan 15, 2026. It is now read-only.

[Discussion] Minimum Python 3 version required for next release  #389

Closed

Description

@marcbonnici

For the next release of devlib Python 2 support will be dropped and we will be completely switching to Python 3. This seems like a good time to define what the minimum version of Python 3 will be used going forward.

Our initial thoughts were to set this as Python 3.6 as this seemed to have a large adoption however comments from #387 indicate this could cause issues for those using still using Python 3.5 and therefore this may be a better option.

Therefore opening this issue to discuss the pros and cons of each.

Activity

  1. setrofim commented on May 22, 2019

    @setrofim
    Contributor

    All in all, we might be able to require Python >=3.6 but that means asking people to use PPA. Do you have some kind of informal list of things that are desirable in 3.6 and not in 3.5 ? (formatted literals are definitely desirable :-) but may not be big enough to warrant dropping native xenial support :-( ).

    Release notes for 3.6 are here: https://docs.python.org/3/whatsnew/3.6.html

    Having looked through those again, the summary is that there is quite a lot there that we would like to be able to use in WA, but there is nothing that is "essential". So if dropping support for version 3.5 means that a lot of infrastructure would require to be updated, I think we can live without the 3.6 features for now.

    Specifically, I see the following new features and improvements to existing features being useful for WA:

    • PEP487:"Simpler customization of class creation" and "Descriptor Protocol Enhancements" would allow some plugin code to be a lot simpler.
    • PEP519: "FS path protocol" -- given how much path manipulation and tracking happens inside devlib and WA, if would be nice to be able to encapsulate some of it inside path objects.
    • PEP498 and PEP515: while these are basically just syntactic sugar, I can see them making code significantly more readable in some cases. (PEP498 is what triggered this whole discussion).
    • Other things, such as PEP525, PEP530, and PEP526, are not immediately relevant to the current code, but I can see them being useful in the future.
  2. douglas-raillard-arm commented on May 23, 2019

    @douglas-raillard-arm
    Collaborator

    PEP519: "FS path protocol" -- given how much path manipulation and tracking happens inside devlib and WA, if would be nice to be able to encapsulate some of it inside path objects.

    Some tools (exekall) in LISA use pathlib.Path objects extensively. The main annoyance with <3.6 is that str() needs to be called all the time before feeding them to most of the library, but these str() can be cleaned up very easily the day 3.5 support is dropped.

    PEP487:"Simpler customization of class creation"

    Would be also useful in LISA to get rid of some metaclasses, and the potential (trivial) metaclass conflicts that can appear.

    Other useful additions to Python 3.6:

  3. setrofim commented on Jun 19, 2019

    @setrofim
    Contributor

    A point was made that this discussion was never concluded; so I'm going to make the following call: We're going to continue supporting Python 3.5 for at least the next release in order to avoid migration hassle for infrastructure running on Ubuntu 16.04 (which still appears to be fairly wide-spread). This decision will be revisited for future releases.

    Please feel free to re-open the issue if you strongly disagree with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions