Skip to content

Fix verbose console formatting for some types #1073

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alexmojaki opened this issue May 14, 2025 · 3 comments · Fixed by #1096
Closed

Fix verbose console formatting for some types #1073

alexmojaki opened this issue May 14, 2025 · 3 comments · Fixed by #1096
Labels
bug Bug related to the Logfire Python SDK good first issue Good for newcomers

Comments

@alexmojaki
Copy link
Contributor

import datetime
import decimal
from enum import Enum, IntEnum, StrEnum

import logfire


class MyEnum(StrEnum):
    foo = 'foo'


class MyEnum2(IntEnum):
    foo = 3


class MyEnum3(Enum):
    foo = 3


logfire.configure(console=logfire.ConsoleOptions(verbose=True))


logfire.info(
    'hi',
    d=datetime.datetime.now(),
    v=decimal.Decimal('1.0'),
)
logfire.info(
    'hi',
    e1=MyEnum.foo,
    e2=MyEnum2.foo,
    e3=MyEnum3.foo,
)

Output:

11:07:08.675 hi
             │ scratch_1499.py:23 info
             │ d=2025-05-14T13:07:08.652694
             │ v=1.0
11:07:08.675 hi
             │ scratch_1499.py:24 info
             │ e1=<MyEnum.foo: 'foo'>
             │ e2=MyEnum2(<MyEnum2.foo: 3>)
             │ e3=MyEnum3(3)

All the values should look like reprs. The enums are an inconsistent mess.

Following up on #1063

Previously these raised errors or did other nonsense, that was fixed in #1071 and #1072

@alexmojaki alexmojaki added bug Bug related to the Logfire Python SDK good first issue Good for newcomers labels May 14, 2025
@sbhrwlr
Copy link
Contributor

sbhrwlr commented May 28, 2025

Hey @alexmojaki Can you explain the reasoning behind how enum values are represented in the logs?

For example:

  1. e1: StrEnum<MyEnum.foo: 'foo'>
  2. e2: IntEnumMyEnum2(<MyEnum2.foo: 3>)
  3. e3: EnumMyEnum3(3)

Is there a specific reason for these different formats instead of using a consistent repr like <EnumName.member: value> for all enum types?

@alexmojaki
Copy link
Contributor Author

It's a bug. I think MyEnum3(3) is the only one looking the way it should.

sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 29, 2025
sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 29, 2025
@sbhrwlr
Copy link
Contributor

sbhrwlr commented May 29, 2025

@alexmojaki I have raised a PR to address this: PR

sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 29, 2025
sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 30, 2025
sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 30, 2025
sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 30, 2025
sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 30, 2025
sbhrwlr pushed a commit to sbhrwlr/logfire that referenced this issue May 30, 2025
alexmojaki pushed a commit that referenced this issue Jun 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug related to the Logfire Python SDK good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants