lint issue fixing

Signed-off-by: Nikhil Suri <[email protected]>

Author: nikhilsuri-db

src/databricks/sql/client.py

@@ -326,7 +326,11 @@ def read(self) -> Optional[OAuthToken]:
         # Determine proxy usage
         use_proxy = self.http_client.using_proxy()
         proxy_host_info = None
-        if use_proxy and self.http_client.proxy_uri and isinstance(self.http_client.proxy_uri, str):
+        if (
+            use_proxy
+            and self.http_client.proxy_uri
+            and isinstance(self.http_client.proxy_uri, str)
+        ):
             parsed = urlparse(self.http_client.proxy_uri)
             proxy_host_info = HostDetails(
                 host_url=parsed.hostname or self.http_client.proxy_uri,

src/databricks/sql/common/unified_http_client.py

@@ -50,7 +50,7 @@ def __init__(self, client_context):
         """
         self.config = client_context
         # Since the unified http client is used for all requests, we need to have proxy and direct pool managers
-        # for per-reques ̰ˇt proxy decisions.
+        # for per-request proxy decisions.
         self._direct_pool_manager = None
         self._proxy_pool_manager = None
         self._retry_policy = None

src/databricks/sql/telemetry/models/event.py

@@ -155,15 +155,6 @@ class ChunkDetails(JsonSerializableMixin):
     Contains detailed metrics about chunk downloads during result fetching.
 
     These metrics are accumulated across all chunk downloads for a single statement.
-    In Java, this is populated by the StatementTelemetryDetails tracker as chunks are downloaded.
-
-    Tracking approach:
-    - Initialize total_chunks_present from result manifest
-    - For each chunk downloaded:
-      * Increment total_chunks_iterated
-      * Add chunk latency to sum_chunks_download_time_millis
-      * Update initial_chunk_latency_millis (first chunk only)
-      * Update slowest_chunk_latency_millis (if current chunk is slower)
 
     Attributes:
         initial_chunk_latency_millis (int): Latency of the first chunk download
@@ -197,11 +188,6 @@ class ResultLatency(JsonSerializableMixin):
         result_set_ready_latency_millis (int): Time until query results are ready (execution phase)
         result_set_consumption_latency_millis (int): Time spent fetching/consuming results (fetch phase)
 
-    Note:
-        Java implementation includes private field 'startTimeOfResultSetIterationNano' for internal
-        tracking (not serialized to JSON). When implementing tracking in Python, use similar approach:
-        - Record start time on first fetchone/fetchmany/fetchall call
-        - Calculate total consumption latency when iteration completes or cursor closes
     """
 
     result_set_ready_latency_millis: Optional[int] = None
@@ -213,23 +199,6 @@ class OperationDetail(JsonSerializableMixin):
     """
     Contains detailed information about the operation being performed.
 
-    This provides more granular operation tracking than statement_type, allowing
-    differentiation between similar operations (e.g., EXECUTE_STATEMENT vs EXECUTE_STATEMENT_ASYNC).
-
-    Tracking approach:
-    - operation_type: Map method name to operation type enum
-      * Java maps: executeStatement -> EXECUTE_STATEMENT
-      * Java maps: listTables -> LIST_TABLES
-      * Python could use similar mapping from method names
-
-    - is_internal_call: Track if operation is initiated by driver internally
-      * Set to true for driver-initiated metadata calls
-      * Set to false for user-initiated operations
-
-    - Status polling: For async operations
-      * Increment n_operation_status_calls for each status check
-      * Accumulate operation_status_latency_millis across all status calls
-
     Attributes:
         n_operation_status_calls (int): Number of status polling calls made
         operation_status_latency_millis (int): Total latency of all status calls