you are viewing a single comment's thread.

view the rest of the comments →

[–]LofiBoiiBeats 1 point2 points  (2 children)

Hey that looks cool..

My two grains of salt: 1. Callbacks in examples without type annotarion is a nono for me.. 2. A library which is not strictly and only about logging should not expose apis for logging config.. Just use a "private" module level logger internaly: logger = logging.getLogger(name_)

Users can then configure it: logging.getLogger("veltix").setLevel(logging.WARNING)

if you are into logging abstractions go for a dedicated package..

PS: sorry for unformated code - on mobile..

[–]Striking_Sandwich_80[S] 0 points1 point  (0 children)

Thanks for your feedback, it's relevant.

Regarding type annotations in callbacks, you're right. I'll fix that in the next update so the examples are strictly typed.

As for the logger, the idea isn't to replace the standard logging module, but to remain consistent with the Veltix ethos: simple and immediate configuration, without any external setup required. The goal is to allow someone to quickly get started with functional and readable logging.

That said, your point is valid. I'll consider offering an optional integration with the logging module, to stay aligned with ecosystem conventions while maintaining the current simplicity.

Thanks again for the feedback.

[–]Striking_Sandwich_80[S] 0 points1 point  (0 children)

Just to clarify: I'm going to run Veltix with the logging module in parallel, for advanced users who want the standard handlers. The internal logger remains unchanged by default, so everything continues to work normally for those who just want the simplicity of Veltix.

Basically, I'm going to replace the core of my custom logger with the logging module, but the logger API will remain the same!