Removed quidda dependency

[ternaus]

No description provided.

[sourcery-ai]

PR Type: Refactoring

PR Summary: This pull request focuses on removing the dependency on 'qudida' and refactoring the domain adaptation functionality within the albumentations library. It introduces a new file, 'domain_adaptation_functional.py', which encapsulates the previously external dependency logic. Additionally, the PR updates various files to accommodate this change, including adjustments to the CI workflow, pre-commit configuration, and the core types definitions. It also ensures that the necessary functions are imported from the new module, maintaining the library's functionality while eliminating the external dependency.

Decision: Comment

📝 Type: 'Refactoring' - not supported yet.

• Sourcery currently only approves 'Typo fix' PRs.

✅ Issue addressed: this change correctly addresses the issue or implements the desired feature.

No details provided.

📝 Complexity: the changes are too large or complex for Sourcery to approve.

• Unsupported files: the diff contains files that Sourcery does not currently support during reviews.

General suggestions:

• Ensure that the removal of 'qudida' does not impact any undocumented use cases within the library.
• Consider adding a brief documentation or comments within 'domain_adaptation_functional.py' to explain the purpose and usage of the newly introduced functions, enhancing maintainability.
• Review the changes to ensure that all references to 'qudida' and its functionalities are appropriately replaced or removed across the library.
• Verify that the new implementation does not introduce any performance regressions compared to the 'qudida'-based solution.

albumentations/augmentations/transforms.py: Consider simplifying the introduction of new types by using Python's `Enum` to maintain readability and reduce complexity.

I appreciate the effort to improve type safety and clarity in the codebase. However, the introduction of new types like ImageMode and SpatterMode, along with the expanded import statements, seems to add a layer of complexity that might not be necessary. A more streamlined approach could be to leverage Python's built-in Enum for defining modes. This would maintain the benefits of explicit type checking and clear enumeration of valid options without the overhead of custom type definitions and expanded imports. Here's a simplified example using Enum:

from enum import Enum, auto

class Mode(Enum):
    CV = auto()
    PIL = auto()
    RAIN = auto()
    MUD = auto()

def apply_mode(mode: Mode = Mode.CV):
    # Example function demonstrating Enum usage

This approach keeps the code simple and Pythonic, aligning with the principle of readability and maintainability.

albumentations/core/types.py: The code changes enhance clarity and maintainability through more specific type annotations without increasing complexity.

After reviewing the changes, I see that the introduction of Literal from the typing module and the specific literals for ImageMode and SpatterMode enhance the clarity and specificity of the type annotations. This approach does not increase the complexity of the code. Instead, it provides explicit documentation on the expected values for these variables, which aids in readability and maintainability. By making the acceptable values clear, it also enables more effective static type checking, potentially catching bugs related to incorrect value assignments early in the development process. Overall, these changes leverage Python's type hinting features to improve the robustness and understandability of the code without negatively impacting its complexity.

Thanks for using Sourcery. We offer it for free for open source projects and would be very grateful if you could help us grow. If you like it, would you consider sharing Sourcery on your favourite social media? ✨

Share Sourcery

• X
• Mastodon
• LinkedIn
• Facebook

---

Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.