logging-objects-with-schema 1.0.2__tar.gz → 1.0.4__tar.gz

{logging_objects_with_schema-1.0.2 → logging_objects_with_schema-1.0.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: logging-objects-with-schema
-Version: 1.0.2
+Version: 1.0.4
 Summary: Schema-aware Python logging with strict extra validation and schema-driven field projection.
 Keywords: logging,schema,validation,structured-logging,structured-logs
 Author: Dmitrii Safronov
@@ -23,6 +23,13 @@ Description-Content-Type: text/markdown
 
 # python-logging-objects-with-schema
 
+Arbitrary `extra` fields let log producers use different names, structures, and
+types for the same information, making downstream searches, alerts, and
+dashboards harder to maintain. A shared schema makes these structured fields a
+contract between producers and consumers. `SchemaLogger` emits the valid fields
+and reports data-validation violations separately, so a malformed field does
+not discard the valid part of the record.
+
 `SchemaLogger` extends Python's standard `logging.Logger` with schema-driven
 validation and projection of `extra` fields. It preserves the standard logging
 API while invalid structured data is dropped and reported separately.
@@ -236,8 +243,10 @@ An example of a valid empty schema (no leaves, no problems):
 - **`item_type`**: Optional field for list-typed leaves. Must be a string if
   present. See "List-typed fields" section below.
 - **Root key restrictions**: Root keys cannot conflict with standard `logging`
-  module fields (e.g., `name`, `levelno`, `pathname`). Such conflicts cause
-  schema validation to fail.
+  module fields (e.g., `name`, `levelno`, `pathname`). This includes the
+  `message` and `asctime` fields, which are populated by formatters and are
+  rejected by `logging.Logger.makeRecord()`. Such conflicts cause schema
+  validation to fail.
 
 **List-typed fields:**
 

{logging_objects_with_schema-1.0.2 → logging_objects_with_schema-1.0.4}/README.md

@@ -1,5 +1,12 @@
 # python-logging-objects-with-schema
 
+Arbitrary `extra` fields let log producers use different names, structures, and
+types for the same information, making downstream searches, alerts, and
+dashboards harder to maintain. A shared schema makes these structured fields a
+contract between producers and consumers. `SchemaLogger` emits the valid fields
+and reports data-validation violations separately, so a malformed field does
+not discard the valid part of the record.
+
 `SchemaLogger` extends Python's standard `logging.Logger` with schema-driven
 validation and projection of `extra` fields. It preserves the standard logging
 API while invalid structured data is dropped and reported separately.
@@ -213,8 +220,10 @@ An example of a valid empty schema (no leaves, no problems):
 - **`item_type`**: Optional field for list-typed leaves. Must be a string if
   present. See "List-typed fields" section below.
 - **Root key restrictions**: Root keys cannot conflict with standard `logging`
-  module fields (e.g., `name`, `levelno`, `pathname`). Such conflicts cause
-  schema validation to fail.
+  module fields (e.g., `name`, `levelno`, `pathname`). This includes the
+  `message` and `asctime` fields, which are populated by formatters and are
+  rejected by `logging.Logger.makeRecord()`. Such conflicts cause schema
+  validation to fail.
 
 **List-typed fields:**
 

{logging_objects_with_schema-1.0.2 → logging_objects_with_schema-1.0.4}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "uv_build"
 
 [project]
 name = "logging-objects-with-schema"
-version = "1.0.2"
+version = "1.0.4"
 description = "Schema-aware Python logging with strict extra validation and schema-driven field projection."
 readme = "README.md"
 requires-python = ">=3.11"

{logging_objects_with_schema-1.0.2 → logging_objects_with_schema-1.0.4}/pyproject.toml.orig

@@ -4,7 +4,7 @@ build-backend = "uv_build"
 
 [project]
 name = "logging-objects-with-schema"
-version = "1.0.2"
+version = "1.0.4"
 description = "Schema-aware Python logging with strict extra validation and schema-driven field projection."
 readme = "README.md"
 requires-python = ">=3.11"

{logging_objects_with_schema-1.0.2 → logging_objects_with_schema-1.0.4}/src/logging_objects_with_schema/schema_applier.py

@@ -11,11 +11,20 @@ from .errors import _DataProblem
 from .schema_loader import _CompiledSchema, _SchemaLeaf
 
 
+def _safe_repr(value: Any) -> str:
+    """Represent diagnostic data without propagating user __repr__ failures."""
+    try:
+        return repr(value)
+    except Exception:
+        # Do not format the value or exception again: either may have a broken repr.
+        return "<unrepresentable value>"
+
+
 def _create_validation_error_dict(field: str, error: str, value: Any) -> dict[str, Any]:
     """Create a dict for a single validation error.
 
-    All values are wrapped in repr() to ensure any type is representable
-    and special characters cannot cause issues downstream.
+    All values use safe repr() formatting. If user code raises during repr(),
+    a constant placeholder preserves the validation diagnostic.
 
     Args:
         field: Field name that caused the validation error.
@@ -23,12 +32,12 @@ def _create_validation_error_dict(field: str, error: str, value: Any) -> dict[st
         value: Invalid value that caused the error.
 
     Returns:
-        Dict with field, error, and value (all via repr() for safety).
+        Dict with field, error, and value as safely represented strings.
     """
     return {
-        "field": repr(field),
-        "error": repr(error),
-        "value": repr(value),
+        "field": _safe_repr(field),
+        "error": _safe_repr(error),
+        "value": _safe_repr(value),
     }
 
 

{logging_objects_with_schema-1.0.2 → logging_objects_with_schema-1.0.4}/src/logging_objects_with_schema/schema_loader.py

@@ -645,11 +645,16 @@ def _get_builtin_logrecord_attributes() -> set[str]:
     Returns:
         Set of attribute names that are reserved by the logging system.
         Examples include: 'name', 'levelno', 'pathname', 'lineno', 'msg', etc.
+        Also includes 'message' and 'asctime', which are not set on a fresh
+        LogRecord instance but are rejected by Logger.makeRecord() and
+        populated by formatters.
 
     Example:
         >>> forbidden = _get_builtin_logrecord_attributes()
         >>> "name" in forbidden
         True
+        >>> "message" in forbidden
+        True
         >>> "ServicePayload" in forbidden
         False
     """
@@ -672,6 +677,12 @@ def _get_builtin_logrecord_attributes() -> set[str]:
         if not callable(attr_value):
             forbidden.add(attr_name)
 
+    # makeRecord() rejects these names even though dir(record) does not list
+    # them: both "message" and "asctime" are set by Formatter.format() before
+    # formatting. Without this, such root keys would pass schema validation
+    # and later raise KeyError when a log record is created.
+    forbidden.update({"message", "asctime"})
+
     return forbidden