Skip to content

Support for Python 2.6 not stated #453

Description

@andy-maier

I am maintaining a project that still supports Python 2.6, and I was glad to see that commit 9989f89 added a workaround for OrderedDict in support of Python 2.6.

However, the PyPI package information of GitPython 2.0.3 does not mention Python 2.6.

I would very much see the support for Python 2.6 in this package continued, as long as it can reasonably be maintained, and I suggest to add Python 2.6 to the package metadata. Probably it would be good to also state (maybe in the package description text that appears on PyPI) that the Python 2.6 support is on a best-can-do basis only.

Activity

  1. Byron commented on May 30, 2016

    @Byron
    Member

    What I could easily do is to add this information to the pypi package text, even though I am not sure that it will be read. The README also has no information about that either just yet.

    About pypi, I totally see your point, and was thinking about adding py2.6 to it myself, yet came to the conclusion that this only allows to indicate 100% compatibility. It could also be read by tools which make the wrong conclusions. What do you think about this objection ?

  2. andy-maier commented on May 31, 2016

    @andy-maier
    ContributorAuthor

    I thought about your argument, and I still think the PyPI metadata for 2.6 should be added, as long as it seems to work on 2.6. In case some unsurmountable problem occurs on 2.6, (or even if a problem occurs that could be solved but that you don't want to solve anymore), then you can make the decision at that point to drop support for 2.6 and you can remove the metadata tag for 2.6 again in a release update.

    If tools parse the metadata tag as long as it is on a release, they conclude the package can be used on 2.6, which is what you want to express with it.

    I think the real concern is the unknowns of potential future problems, and whether they can be solved if they occur. My take there is simply as long as you don't know of any problems, it works. And you can only tell whether a problem can be solved or not when it has occurred.

  3. Byron commented on Jun 1, 2016

    @Byron
    Member

    @andy-maier Thanks a bunch for your argumentation - I like the idea of stating the intend, while waiting for people posting their issues. Will make the respective change in a moment.

  4. added this to the v2.0.6 - Bugfixes milestone on Jun 1, 2016
  5. added a commit that references this issue on Jan 24, 2026
    543d900
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions