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

{logging_objects_with_schema-1.0.3 → 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.3
+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.3 → 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.3 → 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.3"
+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.3 → 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.3"
+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.3 → 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