🐛 Fix verbose console formatting for enum types (#1073)

[sbhrwlr]

Fixes #1073
Change:
Explicitly handled Enums by returning logfire_json_dumps(value), which ensures consistent output across all Enum types.

How I Tested:
Manually tested with all Enum types (Enum, IntEnum, StrEnum, Flag, IntFlag). Please validate the output below for each Enum variant.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[alexmojaki]

Thanks! Please extend test_other_json_schema_types to cover enums.

Also note that this PR doesn't close the issue as decimals and datetimes are still incorrect.

[sbhrwlr]

@alexmojaki Changes include a fix, format updates in tests, and new test cases for different enum types. Let me know if anything needs attention.

[alexmojaki]

This part can't change. The actual attributes should contain the kind of data you'd expect to find in JSON. Python reprs should only be in the console.

[sbhrwlr]

You're right, this behavior stems from Pydantic's data serialization approach. Refer json_encoder.py method _pydantic_model_encoder

The Problem

When using the default model_dump(), Pydantic preserves Python objects in their native form:

from pydantic import BaseModel
from fractions import Fraction
from datetime import datetime

class MyModel(BaseModel):
   x: Fraction
   y: datetime

model = MyModel(x=Fraction(1, 3), y=datetime.now())

Serialization behaviour comparison

# Default mode - preserves Python objects
model.model_dump()
# Output: {'x': '1/3', 'y': datetime.datetime(2025, 5, 30, 0, 29, 36, 610411)}

# JSON mode - converts to JSON-serializable types
model.model_dump(mode="json")
# Output: {'x': '1/3', 'y': '2025-05-30T00:29:36.610411'}

The Challenge

Using model_dump(mode="json") would fix serialization consistency but breaks the test_recursive_objects test.
so should we use model_dump(mode="json") and change test_recursive_objects accordingly?

[alexmojaki]

No, it's not about pydantic models. We always want datetimes to be represented as ISO strings in the attributes, even if they're at the top level.

[sbhrwlr]

@alexmojaki This behavior should be consistent across similar cases. For instance, I tested using Fraction(3, 4) at the root level. Instead of getting '3/4' as the output, the value returned was Fraction(3, 4) — which is its repr().

[alexmojaki]

It just so happens that Pydantic dumps fractions to strings (which TBH I find odd in Python mode) and that logfire doesn't have any handling for fractions. This isn't intentional. It would make sense for logfire to always produce 3/4 too.

[sbhrwlr]

@alexmojaki Tried these changes:

• Introduced dedicated methods: _format_date, _format_datetime, _format_time, selected via x-python-datatype in the schema.
• Added x-python-datatype: Added x-python-datatype in the schema for datetime, date, time & decimal
• Updated formatter to parse string values using ISO format methods or use the object directly if already the correct type.
• Updated tests to ensure all edge cases and input types are handled.

[alexmojaki]

Please check that it still looks right in the logfire UI, the x-python-datatype might change things.

[sbhrwlr]

Sure, @alexmojaki Please check below screenshot for local console and logfire UI.

Test Code

logfire.info(
    'sample test new with datetime, date, time, and decimal',
    dt=datetime(2025, 5, 30, 12, 34, 56, 789000),
    da=date(2025, 5, 30),
    ti=time(12, 34, 56, 789000),
    dec=Decimal(1.0)
)

Output Comparison

Local Console Output

Logfire UI Output

@alexmojaki let me know if there are any concerns