tests: remove imports that were deprecated in Python 3.9 #8643
Conversation
And also `abstractstaticmethod`, which was deprecated in 3.3.
WalkthroughThe changes in this pull request focus on updating type annotations throughout various test files in the codebase. Specifically, the modifications involve transitioning from types defined in the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
tests/python/cli/example_parameterized_function.py (1)
26-26: LGTM! Consider adding Python version compatibility note.The change from
Listtolisttype annotation aligns with modern Python practices. This is a good improvement as it removes dependency on the deprecated typing module imports.Consider adding a comment indicating the minimum Python version required for this syntax:
def detect( context: cvataa.DetectionFunctionContext, image: PIL.Image.Image + # Requires Python 3.9+ ) -> list[models.LabeledShapeRequest]:tests/python/sdk/test_organizations.py (1)
Line range hint
1-100: Consider adding a changelog entry.Since this is part of a broader effort to modernize the codebase (following PR #8626), it would be helpful to document these changes in the changelog to track the progression of Python 3.9 compatibility updates.
tests/python/shared/fixtures/init.py (1)
161-164: LGTM! Type hint updates align with PEP 585.The changes from
Listtolistin type hints are correct and follow Python's type annotation improvements (PEP 585).If you're planning to support Python 3.10+, you could further simplify these type hints using the union operator
|:-def docker_exec_cvat(command: Union[list[str], str]): +def docker_exec_cvat(command: list[str] | str): -def kube_exec_cvat(command: Union[list[str], str]): +def kube_exec_cvat(command: list[str] | str):Also applies to: 167-170
tests/python/rest_api/test_tasks.py (2)
733-733: Type annotations improved for API version and function parametersThe type hints have been enhanced to be more precise and descriptive:
api_versionparameter now usesUnion[int, tuple[int]]to properly type both single version numbers and version tuples- Function parameters are now properly typed with
list[str],dict[str, Any]etc.Consider adding docstrings to document the expected format and valid values for these parameters.
Also applies to: 755-755, 1514-1524
Line range hint
3850-5238: Completed type annotation coverage for remaining methodsType hints have been added consistently across:
- API version parameters
- Generator return types
- List parameter types
Consider adding type hints for local variables where type inference may not be obvious to improve code readability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (31)
tests/python/cli/example_function.py(1 hunks)tests/python/cli/example_parameterized_function.py(1 hunks)tests/python/cli/util.py(3 hunks)tests/python/rest_api/test_analytics_reports.py(2 hunks)tests/python/rest_api/test_issues.py(2 hunks)tests/python/rest_api/test_jobs.py(7 hunks)tests/python/rest_api/test_labels.py(4 hunks)tests/python/rest_api/test_memberships.py(2 hunks)tests/python/rest_api/test_projects.py(5 hunks)tests/python/rest_api/test_quality_control.py(15 hunks)tests/python/rest_api/test_remote_url.py(2 hunks)tests/python/rest_api/test_requests.py(5 hunks)tests/python/rest_api/test_tasks.py(31 hunks)tests/python/rest_api/utils.py(11 hunks)tests/python/sdk/fixtures.py(2 hunks)tests/python/sdk/test_auto_annotation.py(8 hunks)tests/python/sdk/test_client.py(5 hunks)tests/python/sdk/test_datasets.py(2 hunks)tests/python/sdk/test_issues_comments.py(2 hunks)tests/python/sdk/test_jobs.py(2 hunks)tests/python/sdk/test_organizations.py(1 hunks)tests/python/sdk/test_projects.py(2 hunks)tests/python/sdk/test_pytorch.py(3 hunks)tests/python/sdk/test_tasks.py(2 hunks)tests/python/sdk/test_users.py(1 hunks)tests/python/sdk/util.py(2 hunks)tests/python/shared/fixtures/data.py(1 hunks)tests/python/shared/fixtures/init.py(2 hunks)tests/python/shared/utils/config.py(1 hunks)tests/python/shared/utils/helpers.py(2 hunks)tests/python/shared/utils/resource_import_export.py(7 hunks)
✅ Files skipped from review due to trivial changes (2)
- tests/python/shared/fixtures/data.py
- tests/python/shared/utils/config.py
🔇 Additional comments (82)
tests/python/cli/example_function.py (1)
18-18: LGTM! Type annotation update aligns with modern Python practices.
The change from List to list type annotation is consistent with Python 3.9+ standards, which support using built-in types for annotations. This modification improves code readability while maintaining the same functionality.
tests/python/sdk/test_users.py (1)
19-20: LGTM! The type annotation changes align with PEP 585.
The transition from typing.Tuple to built-in tuple for type annotations is correct and follows Python's modernization efforts (PEP 585).
Let's verify the project's Python version compatibility:
✅ Verification successful
Based on the output, I found clear evidence that the project requires Python 3.9 or higher in multiple places:
- In setup.py:
python_requires=">=3.9"- In pyproject.toml:
target-version = ['py39']- In GitHub workflows, Python 3.9 is used for testing:
- uses: actions/setup-python@v5
with:
python-version: '3.9'Therefore, I can generate the final response:
The type annotation changes are compatible with the project's Python version requirements
The use of built-in tuple type annotation is safe since the project requires Python ≥3.9, which fully supports PEP 585 built-in type annotations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the project's minimum Python version is compatible with PEP 585 (Python 3.9+)
# Expected: Find setup.py, pyproject.toml, or similar files containing Python version requirements
# Look for Python version specifications in various config files
echo "Checking Python version requirements..."
rg -l "python.*version|python_requires|python.*>=|python.*>|Framework :: Python" --type yaml --type toml --type ini setup.cfg setup.py pyproject.toml requirements*.txt
Length of output: 288
Script:
#!/bin/bash
# Let's try a different approach to find Python version requirements
# First, check if setup.py exists and look for Python version
echo "=== Checking setup.py ==="
fd "setup.py" --type f --exec cat {}
echo -e "\n=== Checking pyproject.toml ==="
fd "pyproject.toml" --type f --exec cat {}
echo -e "\n=== Checking setup.cfg ==="
fd "setup.cfg" --type f --exec cat {}
echo -e "\n=== Checking tox.ini for Python versions ==="
fd "tox.ini" --type f --exec cat {}
# Also check for any GitHub workflow files that might specify Python version
echo -e "\n=== Checking GitHub workflows ==="
fd ".*yml" .github/workflows/ --type f --exec cat {}
Length of output: 73631
tests/python/rest_api/test_remote_url.py (2)
8-8: LGTM!
The Any import from typing module is still necessary and valid as it wasn't deprecated in Python 3.9.
24-24: LGTM! Good modernization of type hints
The change from Dict to dict aligns with PEP 585 (Type Hinting Generics In Standard Collections), which made built-in collections support type annotations in Python 3.9+. This is a positive modernization that maintains the same functionality while using more idiomatic Python 3.9+ syntax.
tests/python/sdk/util.py (2)
6-6: LGTM! Good modernization of imports
The change from typing.Container to collections.abc.Container aligns with Python's modernization efforts and removes usage of deprecated imports.
19-19: LGTM! Proper modernization of type hints
The change from Tuple to tuple follows PEP 585 and modern Python type hinting practices. This is a good improvement that maintains type safety while using the newer syntax.
Let's verify that similar type hint modernizations are consistent across the test files:
✅ Verification successful
Type hint modernization is consistent across the codebase
The search results confirm that all type hint usage in the test files follows the modern Python type hinting style using lowercase tuple instead of Tuple. The file under review and other test files consistently use the PEP 585 compliant tuple[...] syntax. No instances of the old-style Tuple[...] were found in the codebase, indicating proper modernization of type hints throughout the test files.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining usage of typing.Tuple in test files
# Expected: No occurrences of the old style type hints
# Search for any remaining Tuple imports from typing in test files
rg "from typing import .*Tuple" "tests/"
# Search for any remaining Tuple type hints
rg "Tuple\[" "tests/"
Length of output: 62
Script:
#!/bin/bash
# Let's try a more comprehensive search for type hint patterns
# 1. Look for any imports from typing module
# 2. Look for both Tuple and tuple type hints with context
# 3. Check specifically the test file we're reviewing
# Check all typing imports in tests
rg "from typing import" "tests/" -A 2
# Look for both Tuple and tuple type hints with context
rg -i "tuple\[" "tests/" -A 1
# Specifically examine the file under review
cat "tests/python/sdk/util.py"
Length of output: 18886
tests/python/shared/utils/helpers.py (2)
6-6: LGTM! Good modernization of imports
The change to import Generator from collections.abc instead of typing aligns with modern Python practices and PEP 585.
31-34: LGTM! Type hints modernization looks good
The update to use built-in generics (list, tuple) instead of typing equivalents follows PEP 585 and modern Python practices.
Let's verify that similar type hint updates are consistent across test files:
✅ Verification successful
Type hints are consistently using modern syntax across test files
The verification shows that:
- The file under review uses modern type hints with
list[str]andlist[tuple[int, int]] - Other test files also consistently use the modern syntax (e.g.,
list[str],list[models.Label],list[tuple[int, int]]) - No occurrences of old-style
List[]orTuple[]type hints were found in the test files - The changes align well with the codebase's type hint style
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining usage of typing.List or typing.Tuple in test files
# Expected: No occurrences of old-style type hints
echo "Checking for old-style type hints in test files..."
rg -t python "from typing import .*(?:List|Tuple)" tests/
rg -t python "typing\.(?:List|Tuple)" tests/
Length of output: 279
Script:
#!/bin/bash
# Let's try without the -t python flag since it's not recognized
echo "Checking for old-style type hints in test files..."
rg "from typing import .*(?:List|Tuple)" tests/
rg "typing\.(?:List|Tuple)" tests/
# Also check for any Python files in tests directory to ensure we're searching in the right place
echo -e "\nVerifying Python files exist in tests directory:"
fd "\.py$" tests/
Length of output: 2603
Script:
#!/bin/bash
# Let's check the content of a few Python test files to ensure we're searching correctly
# and to verify the type hint usage patterns
echo "Checking content of test files for type hints..."
for file in tests/python/shared/utils/helpers.py tests/python/sdk/test_client.py tests/python/rest_api/test_tasks.py; do
echo -e "\nFile: $file"
echo "----------------------------------------"
grep -A 5 -B 5 "List\[" "$file" || true
grep -A 5 -B 5 "Tuple\[" "$file" || true
grep -A 5 -B 5 "list\[" "$file" || true
grep -A 5 -B 5 "tuple\[" "$file" || true
done
Length of output: 16269
tests/python/sdk/test_organizations.py (2)
18-19: LGTM! Type annotations updated to use built-in types.
The change from Tuple to tuple aligns with modern Python type hinting practices and removes usage of deprecated imports. This is a good modernization that maintains compatibility with Python 3.9+.
Line range hint 1-100: Test structure and coverage look comprehensive.
The test class provides good coverage of organization-related operations including creation, retrieval, listing, updating, and removal. The fixture setup and cleanup are well-implemented with proper resource management.
tests/python/sdk/fixtures.py (3)
74-74: LGTM! Type hint modernization looks good.
The change from Tuple[Client, str] to tuple[Client, str] follows PEP 585 and modern Python type hinting practices.
89-89: LGTM! Type hint modernization is consistent.
The type hint change follows the same pattern as the previous function, maintaining consistency throughout the file.
Line range hint 1-20: Verify removal of typing imports.
Let's check if there are any unused typing imports that should be cleaned up.
✅ Verification successful
No cleanup of typing imports needed
The file uses type annotations with Path, str, and tuple[Client, str], but these types are correctly imported from their respective modules (pathlib.Path) or are built-in types that don't require explicit imports in Python 3.7+. While there was a Tuple import in the git history, it has been correctly updated to use the lowercase tuple built-in type annotation instead.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining typing imports in the file
# Expect: No occurrences of "from typing import" or "import typing"
rg "^(from typing import|import typing)" "tests/python/sdk/fixtures.py"
Length of output: 71
Script:
#!/bin/bash
# Let's check the entire file content to understand the context better
# and look for any typing-related imports or usage
cat "tests/python/sdk/fixtures.py"
Length of output: 2877
Script:
#!/bin/bash
# Let's also check if there are any type annotations or typing usage in the file
# that might suggest we need typing imports
rg ":[^/]" "tests/python/sdk/fixtures.py"
Length of output: 881
Script:
#!/bin/bash
# Check git history for any recently removed typing imports
git log -p "tests/python/sdk/fixtures.py" | rg "^[-+](from typing import|import typing)"
Length of output: 140
tests/python/cli/util.py (4)
11-11: LGTM! Import changes follow Python's modernization path
The changes correctly move towards using built-in type hints and import Generator from collections.abc, which aligns with Python's type hinting best practices.
Also applies to: 13-13
32-32: LGTM! Type hint modernization
The return type annotation change from List[Path] to list[Path] follows PEP 585 guidelines for using built-in collection types in annotations.
74-74: LGTM! Consistent type hint update
The return type annotation change from Dict[str, Any] to dict[str, Any] maintains consistency with the codebase's move towards using built-in types for annotations.
Line range hint 1-89: Verify test coverage remains intact
While the type hint changes are safe, let's verify that the test coverage hasn't been affected by these changes.
✅ Verification successful
Type hint changes are safe and test coverage is intact
The changes are purely type-related updates to modern Python syntax:
- Changed
List[Path]tolist[Path] - Changed
Dict[str, Any]todict[str, Any] - Added
Generatorimport from collections.abc - Removed unused imports
The test file test_cli.py extensively uses all the utility functions (run_cli, generate_images, https_reverse_proxy), and the git diff confirms no functional changes were made to the implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for test files that might be testing this utility file
# and verify they still pass
# Look for test files that import or use this utility file
rg -l "from.*cli.util import|import.*cli.util" "tests/python"
Length of output: 61
Script:
#!/bin/bash
# Let's try a broader search to find test files that might be using these utilities
# First, let's check for direct references to the functions defined in util.py
rg -l "run_cli|generate_images|https_reverse_proxy" "tests/python"
# Also check for test files that might be importing from cli package
rg -l "from.*cli.*import|import.*cli" "tests/python"
# And check if the file itself contains any tests
rg "class.*Test|def test_" "tests/python/cli/util.py"
Length of output: 1480
Script:
#!/bin/bash
# Let's examine the test_cli.py file which directly uses our utility functions
cat "tests/python/cli/test_cli.py"
# Also check the actual changes made to util.py to confirm they're only type-related
git diff HEAD^ HEAD -- tests/python/cli/util.py
Length of output: 12515
tests/python/sdk/test_datasets.py (4)
23-23: LGTM: Good modernization of type hints
The change from Tuple to tuple aligns with PEP 585 and modern Python type hinting practices.
24-24: LGTM: Consistent type hint modernization
The change maintains consistency with the previous update and correctly specifies the expected tuple types.
42-42: LGTM: Consistent type hint usage
The change maintains consistency with the earlier updates and correctly uses the same type hint for the same fixture.
Line range hint 23-42: Verify complete type hint modernization
Let's verify if there are any other type hints from the typing module that could be modernized.
✅ Verification successful
Type hints are already modernized in this file
The verification results show that:
- There are no imports from the
typingmodule - All type hints use the new Python 3.9+ syntax with lowercase
tuple[]notation - No instances of capital-case type hints (List, Dict, etc.) were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining typing module imports and usages
# Look for any remaining imports from typing module
echo "Checking for typing module imports:"
rg "from typing import" "tests/python/sdk/test_datasets.py"
# Look for potential type hints that could be modernized
echo -e "\nChecking for potential type hints to modernize:"
rg -i "List\[|Dict\[|Tuple\[|Set\[|FrozenSet\[|Type\[" "tests/python/sdk/test_datasets.py"
Length of output: 460
tests/python/sdk/test_issues_comments.py (2)
20-21: LGTM! Good modernization of type hints.
The change from Tuple to tuple follows PEP 585 and modern Python type hinting practices, making the code more maintainable and forward-compatible.
141-142: LGTM! Consistent type hint modernization.
The changes maintain consistency with the updates made in TestIssuesUsecases.
tests/python/rest_api/test_memberships.py (2)
7-7: LGTM! Correctly retained the ClassVar import.
The ClassVar import from typing module is correctly maintained as it has no built-in equivalent and is not deprecated.
83-83: LGTM! Type annotation updated to use built-in list type.
The type annotation change from List[str] to list[str] aligns with modern Python type hinting practices (PEP 585) and maintains the same functionality.
tests/python/shared/utils/resource_import_export.py (6)
3-3: LGTM! Import changes align with Python 3.9+ compatibility.
The removal of deprecated imports and retention of necessary typing utilities is appropriate.
Also applies to: 7-7
28-28: LGTM! Consistent type hint modernization across related functions.
The changes maintain consistency in type hint style across the resource parameter functions.
Also applies to: 36-36
46-46: LGTM! Type hint modernization consistent with related functions.
55-56: LGTM! Correct replacement for deprecated @abstractstaticmethod.
The change to separate @staticmethod and @abstractmethod decorators is the proper way to replace the deprecated @abstractstaticmethod. The order of decorators is correct.
68-68: LGTM! Consistent type hint modernization.
223-223: LGTM! Final type hint modernizations are consistent.
The changes complete the modernization of type hints throughout the file.
Also applies to: 238-238
tests/python/sdk/test_projects.py (2)
8-8: LGTM! Correct usage of typing.Optional
The Optional type hint from the typing module is appropriately maintained as it's still the standard way to annotate optional types in Python.
32-33: LGTM! Appropriate modernization of type hints
The changes from Tuple to tuple align with PEP 585 and modern Python typing standards, making the code more maintainable while maintaining type safety.
Let's verify the Python version requirement is properly set:
✅ Verification successful
Based on the search results, I found that:
- In pyproject.toml, the target Python version is set to 'py39':
[tool.black]
line-length = 100
target-version = ['py39']- In cvat-cli/setup.py, the minimum Python version requirement is explicitly set:
python_requires=">=3.9"This confirms that the project requires Python 3.9 or higher, which fully supports the use of built-in collection types as generic types (PEP 585) that was introduced in Python 3.9.
Therefore, I can generate the final response:
✓ Type hint changes are compatible with project's Python version
The changes from Tuple to tuple are safe as the project requires Python 3.9+ which fully supports using built-in collection types in type annotations (PEP 585).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the project's minimum Python version is compatible with these type hints
# Note: These type hints require Python 3.9+
# Look for Python version specifications in common configuration files
echo "Checking Python version requirements..."
rg -l "python.*3\.[0-9]" "setup.py" "pyproject.toml" "requirements*.txt" || echo "No explicit Python version found in common configuration files"
Length of output: 401
Script:
#!/bin/bash
# Let's check for Python version requirements in other common locations and patterns
# Check pyproject.toml content if it exists
if [ -f "pyproject.toml" ]; then
echo "=== pyproject.toml content ==="
cat pyproject.toml
fi
# Look for Python version in any requirements files with different patterns
echo -e "\n=== Searching for requirements files ==="
fd -e txt -e in requirements
# Check for tox.ini
if [ -f "tox.ini" ]; then
echo -e "\n=== tox.ini content ==="
cat tox.ini
fi
# Look for Python version specifications in any file
echo -e "\n=== Searching for Python version specifications in source files ==="
rg "python_requires|python_version|requires-python" -A 2
# Check for GitHub workflow files that might specify Python version
echo -e "\n=== GitHub Workflows Python versions ==="
fd -e yml -e yaml . .github/workflows/ --exec cat {}
Length of output: 71086
tests/python/sdk/test_client.py (1)
24-24: LGTM! Type annotation updates align with modern Python standards.
The changes consistently update type hints from typing module types to their built-in equivalents (PEP 585):
Tuple[Logger, io.StringIO]→tuple[Logger, io.StringIO]List[str]→list[str]
These changes improve code readability while maintaining the same type checking capabilities.
Let's verify no functional changes were introduced:
Also applies to: 97-97, 120-120, 143-143, 185-188
✅ Verification successful
Type annotation changes are safe and correctly implemented
The verification confirms:
- The changes only affect type annotations for
fxt_loggerparameter - The implementation and usage of the fixture remain unchanged
- All occurrences consistently use the updated
tuple[Logger, io.StringIO]type hint - The changes align with Python 3.9+ type hinting standards (PEP 585)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that only type annotation changes were made
# and no functional changes were introduced
# Test: Look for any changes beyond type annotations
# Expect: Only type annotation changes
rg -U 'def test_.*:.*\n.*fxt_logger:.*\n' tests/python/sdk/test_client.py
Length of output: 75
Script:
#!/bin/bash
# Let's try a different approach to verify the changes
# 1. Check the actual content of the test file
cat tests/python/sdk/test_client.py
# 2. Look for any function definitions with fxt_logger parameter
rg -U "def.*\(.*fxt_logger.*\)" tests/python/sdk/test_client.py
Length of output: 10777
tests/python/sdk/test_jobs.py (2)
8-8: LGTM! Correct usage of typing imports.
The Optional import from typing is correctly maintained as it's still the recommended way to handle optional types in Python.
29-30: LGTM! Appropriate type annotation updates.
The changes from Tuple[Client, str] to tuple[Client, str] and Tuple[Logger, io.StringIO] to tuple[Logger, io.StringIO] align with PEP 585's introduction of built-in generic types and the PR's objective to modernize type hints.
Let's verify if there are any remaining uses of deprecated typing imports in this file:
✅ Verification successful
Type hint modernization verified successfully
The file only imports Optional from typing, which is still acceptable as it wasn't deprecated by PEP 585. All other type hints in the file have been properly updated to use the built-in generics, including the changes from Tuple to tuple that were reviewed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining deprecated typing imports
rg -U 'from typing import (?!Optional).*' tests/python/sdk/test_jobs.py
Length of output: 329
Script:
#!/bin/bash
# Search for any remaining typing imports with PCRE2 regex
rg --pcre2 'from typing import (?!Optional).*' tests/python/sdk/test_jobs.py
# Also let's check all typing imports to be thorough
rg 'from typing import' tests/python/sdk/test_jobs.py
Length of output: 162
tests/python/rest_api/test_analytics_reports.py (2)
7-7: LGTM! Correct usage of typing imports
The import statement correctly maintains Any and Optional from the typing module as these special types don't have built-in equivalents.
70-70: LGTM! Proper type annotation update
The change from Dict[str, Any] to dict[str, Any] aligns with PEP 585, which enables the use of built-in collection types in type annotations.
tests/python/rest_api/test_requests.py (4)
90-90: LGTM: Type hint modernization
The update from List[int] to list[int] aligns with PEP 585 and modern Python type hinting practices.
164-164: LGTM: Consistent type hint update
The type hint change maintains consistency with the codebase-wide modernization effort.
184-184: LGTM: Type hint updates for task and job fixtures
The type hint changes in both fixture methods maintain consistency with the modernization pattern.
Also applies to: 198-198
233-233: LGTM: Type hint update with verification needed
The type hint change from List to list is correct. However, since this parameter accepts values of different types (str, int) as shown in the parametrize decorator, consider making the type more specific.
✅ Verification successful
Type hint update is appropriate
The change from List to list is correct and consistent with the codebase. Looking at the test file:
- The
valuesparameter is used with various types as shown in the@pytest.mark.parametrizedecorator - The test accepts both empty lists and lists with strings/integers
- No other type hints in the file use the
typing.Listnotation - The change aligns with Python's built-in type hint support
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any remaining typing.List imports in the test files
rg "from typing import.*List" "tests/"
# Check if there are any remaining List type hints
rg "\bList\[" "tests/"
Length of output: 61
Script:
#!/bin/bash
# Check the test file content to understand the parameter usage
cat "tests/python/rest_api/test_requests.py"
Length of output: 12834
tests/python/rest_api/test_issues.py (1)
370-370: LGTM! Type annotation updated to use built-in generics.
The change from Tuple[Any, List[Dict[str, Any]]] to tuple[Any, list[dict[str, Any]]] aligns with PEP 585 and modern Python type hinting practices. This is a good cleanup that maintains compatibility with Python 3.9+.
tests/python/sdk/test_pytorch.py (3)
56-56: LGTM! Consistent type hint update.
The change maintains consistency with the earlier updates to use built-in tuple type.
300-300: LGTM! Consistent type hint update.
The change maintains consistency with the earlier updates to use built-in tuple type.
36-37: LGTM! Type hint updates align with PEP 585.
The change from Tuple to tuple follows Python 3.9+ best practices for using built-in collection types as generic types.
✅ Verification successful
Type hint changes are consistent with Python 3.9 target version
The change from Tuple to tuple is correct and verified by:
- The project's
pyproject.tomlexplicitly targets Python 3.9 (target-version = ['py39']) - The change is consistent with other test files which also use lowercase
tupletype hints - This follows PEP 585 which made built-in collection types generic in Python 3.9+
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify Python version requirements in project metadata
rg -g "setup.py|pyproject.toml|requirements*.txt" "python.*3\.9"
Length of output: 215
Script:
#!/bin/bash
# Let's check Python version requirements with broader patterns
rg -g "setup.py|pyproject.toml|requirements*.txt" "python.*[>=<].*3\."
# Also check for any Python version related files
fd "setup.py|pyproject.toml|requirements.txt"
# Let's also check if there are any other files with Tuple type hints
rg "Tuple\[" -l
Length of output: 1104
Script:
#!/bin/bash
# Let's check the Python version requirements in the test directory's pyproject.toml
cat tests/python/pyproject.toml
# Also check if there are any other instances of tuple type hints in test files
rg "tuple\[" tests/python/
# Let's also check the content of the main pyproject.toml
cat pyproject.toml
Length of output: 7920
tests/python/sdk/test_tasks.py (1)
33-34: LGTM! Type annotation updates align with modern Python standards.
The change from Tuple[Client, str] to tuple[Client, str] follows PEP 585, which allows using built-in collection types as generic types in Python 3.9+. This modernization improves code clarity while maintaining the same type checking functionality.
tests/python/rest_api/utils.py (3)
7-7: LGTM! Import changes align with PEP 585.
The changes correctly move collection types from typing to collections.abc, which is the recommended approach for Python 3.9+.
Also applies to: 11-11
195-195: LGTM! Type hints updated to use built-in types.
The changes consistently update function signatures to use built-in types instead of those from the typing module, which is the recommended approach for Python 3.9+.
Also applies to: 255-255, 262-262, 269-269, 278-278, 313-313, 320-320
399-401: LGTM! Class and method type hints updated consistently.
The changes systematically update all type hints in class attributes and methods to use built-in types, maintaining consistency throughout the codebase.
Also applies to: 412-412, 432-432, 443-443, 467-467, 489-489, 494-494
tests/python/sdk/test_auto_annotation.py (6)
29-30: LGTM: Type hint modernization in _common_setup
The update from Tuple to tuple aligns with PEP 585's recommendation to use built-in collection types for annotations.
48-48: LGTM: Type hint modernization in TestTaskAutoAnnotation.setup
Consistent update of Tuple to tuple in the setup method signature.
116-116: LGTM: Type hint modernization in detect functions
The return type annotations have been updated from List[models.LabeledShapeRequest] to list[models.LabeledShapeRequest] across multiple detect functions, maintaining consistency throughout the test file.
Also applies to: 170-170, 243-243
572-572: LGTM: Type hint modernization in TorchVision detector classes
The parameter and return type annotations in the TorchVision detector classes have been updated to use built-in types:
List[torch.Tensor]→list[torch.Tensor]List[str]→list[str]List[dict]→list[dict]
Also applies to: 591-591, 596-596
630-630: LGTM: Type hint modernization in TestAutoAnnotationFunctions.setup
Consistent update of Tuple to tuple in the setup method signature.
Line range hint 1-672: Verify test coverage after type hint changes
While the type hint changes are syntactically correct, we should verify that the test suite runs successfully to ensure no runtime issues were introduced.
tests/python/rest_api/test_labels.py (3)
63-63: LGTM: Updated type hints to use built-in collection types
The change from List[Dict] to list[dict] follows PEP 585 and modern Python type hinting practices.
219-219: LGTM: Updated return type annotation to use built-in collection types
The change from Tuple[Any, List[Dict[str, Any]]] to tuple[Any, list[dict[str, Any]]] follows PEP 585 and maintains type safety.
587-588: LGTM: Updated parameter and return type annotations to use built-in collection types
The change from Dict[str, Any] to dict[str, Any] follows PEP 585 and maintains type safety.
tests/python/rest_api/test_quality_control.py (8)
6-6: LGTM: Using collections.abc for abstract base classes.
The import of Iterable from collections.abc follows Python's best practices for type hinting.
87-88: LGTM: Updated to use built-in types for type hints.
The change from Tuple[Dict[str, Any], Dict[str, Any]] to tuple[dict[str, Any], dict[str, Any]] follows PEP 585 recommendations.
119-120: LGTM: Consistent type hint update.
The return type annotation change maintains consistency with PEP 585 recommendations.
253-253: LGTM: Consistent parameter type hint update.
The parameter type annotation change follows PEP 585 recommendations.
312-312: LGTM: Consistent parameter type hint update.
The parameter type annotation change maintains consistency with PEP 585 recommendations.
893-893: LGTM: Consistent parameter type hint update.
The parameter type annotation change maintains consistency with PEP 585 recommendations.
955-955: LGTM: Consistent parameter type hint update.
The parameter type annotation change maintains consistency with PEP 585 recommendations.
1020-1022: LGTM: Consistent type hint updates across multiple functions.
All type annotation changes follow PEP 585 recommendations, maintaining consistency throughout the file.
Also applies to: 1036-1036, 1049-1049
tests/python/rest_api/test_projects.py (5)
19-19: LGTM: Clean import statement.
The import statement for typing module is correctly placed with other imports and only imports the necessary types.
507-507: LGTM: Modern type annotation syntax.
The type annotation for members parameter uses the modern dict[str, str] syntax instead of the deprecated Dict from typing module.
632-632: LGTM: Modern type annotation syntax.
The type annotation for api_version parameter uses the modern tuple[int] syntax instead of the deprecated Tuple from typing module.
781-781: LGTM: Modern type annotation syntax.
The type annotation for api_version parameter uses the modern tuple[int] syntax consistently with other changes.
1106-1106: LGTM: Modern type annotation syntax.
The return type annotation uses the modern list[models.Label] syntax instead of the deprecated List from typing module.
tests/python/rest_api/test_jobs.py (6)
18-18: LGTM! Import statement correctly updated.
The change appropriately retains only the necessary typing imports (Any, Optional, Union) that don't have built-in equivalents in Python 3.9+.
74-74: LGTM! Type annotation correctly updated to use built-in generic.
The change from Dict[str, Any] to dict[str, Any] follows PEP 585 guidelines for using built-in collections as generic types.
83-83: LGTM! Type annotation correctly updated to use built-in generic.
The change from Dict[str, Any] to dict[str, Any] maintains consistency with PEP 585 guidelines.
113-113: LGTM! Type annotation correctly updated to use built-in generic.
The change from Set[str] to set[str] follows the same pattern of using built-in types as generics per PEP 585.
1445-1445: LGTM! Type annotations correctly updated to use built-in generics.
The changes from Tuple[int] to tuple[int] in the method signature and parameter annotations follow PEP 585 guidelines consistently.
Also applies to: 1476-1476, 1478-1478
547-547: LGTM! Type annotation correctly updated to use built-in generic.
The change from Optional[Dict[str, Any]] to Optional[dict[str, Any]] follows PEP 585 guidelines consistently.
tests/python/rest_api/test_tasks.py (4)
2119-2119: Consistent type annotations added for method parameters
Type hints for method_params parameter have been standardized across multiple test methods using set[str].
Also applies to: 2303-2303, 2436-2436
2637-2638: Enhanced type annotations for class attributes and generator methods
The changes improve type safety by:
- Adding proper typing for class attributes using
Union[dict, models.TaskWriteRequest] - Adding return type hints for generator methods using
Generator[tuple[_TaskSpec, int], None, None]
Also applies to: 2702-2702, 2755-2787
Line range hint 2849-2906: Standardized return type annotations for test fixture methods
Return type hints have been consistently applied to test fixture methods using Generator[tuple[_TaskSpec, int], None, None].
Line range hint 3027-3576: Improved type annotations for test methods and utilities
Type hints have been enhanced for:
- Generator methods in test fixtures
- Utility methods like
_compute_annotation_segment_params - Return types for list methods
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #8643 +/- ##
===========================================
- Coverage 74.31% 74.30% -0.02%
===========================================
Files 401 401
Lines 43421 43421
Branches 3951 3951
===========================================
- Hits 32269 32264 -5
- Misses 11152 11157 +5
|
And also
abstractstaticmethod, which was deprecated in 3.3.Motivation and context
This is a continuation of #8626.
How has this been tested?
Checklist
developbranch[ ] I have created a changelog fragment[ ] I have updated the documentation accordingly[ ] I have added tests to cover my changes[ ] I have linked related issues (see GitHub docs)[ ] I have increased versions of npm packages if it is necessary(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)
License
Feel free to contact the maintainers if that's a concern.
Summary by CodeRabbit
list,dict,tuple) instead of their counterparts from thetypingmodule.collections.abcfor certain types.These changes streamline the codebase and ensure compliance with modern Python typing standards without altering existing functionality.