[Feature]: Improve the import times.

[Jatinbhardwaj-093]

Summary

Instead, type-only imports should be guarded using TYPE_CHECKING.

Description

NONE

Background and Context

No response

Current Code Analysis

No response

Issues Identified

No response

Problem

Currently, the project includes some code coverage related to type annotations. However, the current approach of importing type annotations at runtime is unnecessary, since they are only used by the editor for type hints and autocomplete. If there is no runtime type checking, these imports do not need to be evaluated at execution time.

Proposed Solution

from typing import List, Optional

# should be written as

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from typing import List, Optional

Implementation Steps

No response

Acceptance Criteria

No response

Testing Checklist

No response

Benefits

No response

Alternatives Considered

No response

Related Documentation

No response

Additional Context

No response

[PrakshaaleJain]

I noticed while reviewing this that we could use from __future__ import annotations instead of TYPE_CHECKING, as it's the standard approach for handling type annotations.

[Jatinbhardwaj-093]

No, I think you have a misconception about how __future__ works. It’s used to store type annotations as strings, primarily to safeguard against circular type references, forward class definitions, and similar cases.

This is a direct example from the repository:

krkn-ai/krkn_ai/models/cluster_components.py

Lines 65 to 69 in e84edfd

	def get_active_components(self) -> "ClusterComponents":
	"""
	Returns a new ClusterComponents instance with disabled items filtered out.
	This provides a centralized way to filter disabled components for all scenarios.
	"""

If from __future__ import annotations were used, there would be no need to wrap types in quotes, which is cleaner and more modern. However, it’s not a magical solution that automatically resolves all type references. If a type is neither defined nor imported in the file, this will still not work.

I’m not opposed to using future, but that’s a different context from the current suggestion.

[Jatinbhardwaj-093]

I also want to point out that the repository is currently using older typing constructs such as List, Optional, and Dict.
Since Python 3.9+, built-in collection types (list, dict, etc.) and the | union syntax are supported and are now the recommended, more modern approach for type annotations.