Project

General

Profile

Actions

Idea #21356

closed

Remove use of the future library across all our Python tools

Added by Brett Smith 4 months ago. Updated 17 days ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
SDKs
Start date:
05/01/2024
Due date:
Story points:
-

Description

This library was an aid for Python 2/3 compatibility and should no longer be needed. It is no longer maintained, so we need to clean this up to support more modern Python versions. None of our software should list it in install_requires.


Subtasks 1 (0 open1 closed)

Task #21739: Review 21356-clean-importsResolvedPeter Amstutz05/01/2024Actions
Actions #1

Updated by Brett Smith 20 days ago

Actions #2

Updated by Brett Smith 20 days ago

  • Description updated (diff)

The module has been updated to support Python 3.12, but they also announce this is the last release, so we should still excise it.

Actions #3

Updated by Brett Smith 20 days ago

Actions #4

Updated by Brett Smith 20 days ago

  • Target version changed from Future to Development 2024-05-08 sprint
  • Assigned To set to Brett Smith
  • Status changed from New to In Progress
Actions #5

Updated by Brett Smith 20 days ago

21356-clean-imports @ 873fcf181c037cc1e42419bfeaf5bb70c9d9e239 - developer-run-tests: #4193 - failed only on #21660

  • All agreed upon points are implemented / addressed.
    • And then some. This removes all Python 2/3 compatibility imports: all usage of the future and siX compatibility libraries, as well as imports from __future__ and builtins that are noops under Python 3. After this branch, git grep -E '\b(from|import) +(__future__|builtins|future|six)\b' returns no results.
  • Anything not implemented (discovered or discussed during work) has a follow-up story.
    • N/A
  • Code is tested and passing, both automated and manual, what manual testing was done is described
    • See above
  • Documentation has been updated.
    • N/A
  • Behaves appropriately at the intended scale (describe intended scale).
    • Probably slightly improves performance by avoiding list allocations where iteration is sufficient.
  • Considered backwards and forwards compatibility issues between client and server.
    • Super technically every time I change basestring to str that's a potential compatibility break, because bytes also counts as basestring. However, in most cases I was able to convince myself that the code was only intended to handle str in Python 3 anyway, so that seemed like the clearest shift. There was one module deep in the CWL weeds where that wasn't true and so the checks became isinstance(x, (bytes, str)).
  • Follows our coding standards and GUI style guidelines.
    • Yes, and did some opportunistic imports cleanup to better follow PEP 8.
Actions #6

Updated by Peter Amstutz 18 days ago

Brett Smith wrote in #note-5:

21356-clean-imports @ 873fcf181c037cc1e42419bfeaf5bb70c9d9e239 - developer-run-tests: #4193 - failed only on #21660

  • All agreed upon points are implemented / addressed.
    • And then some. This removes all Python 2/3 compatibility imports: all usage of the future and siX compatibility libraries, as well as imports from __future__ and builtins that are noops under Python 3. After this branch, git grep -E '\b(from|import) +(__future__|builtins|future|six)\b' returns no results.
  • Anything not implemented (discovered or discussed during work) has a follow-up story.
    • N/A
  • Code is tested and passing, both automated and manual, what manual testing was done is described
    • See above
  • Documentation has been updated.
    • N/A
  • Behaves appropriately at the intended scale (describe intended scale).
    • Probably slightly improves performance by avoiding list allocations where iteration is sufficient.
  • Considered backwards and forwards compatibility issues between client and server.
    • Super technically every time I change basestring to str that's a potential compatibility break, because bytes also counts as basestring. However, in most cases I was able to convince myself that the code was only intended to handle str in Python 3 anyway, so that seemed like the clearest shift. There was one module deep in the CWL weeds where that wasn't true and so the checks became isinstance(x, (bytes, str)).
  • Follows our coding standards and GUI style guidelines.
    • Yes, and did some opportunistic imports cleanup to better follow PEP 8.

This LGTM

Actions #7

Updated by Brett Smith 17 days ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF