Skip to content

Proposal: Kivy-internal logs should rely on module name rather than manual specification of type #4113

@ngoonee

Description

@ngoonee

Please refer initial issue - #4102 regarding Kivy not handling calls to python's logging module.

As-is, kivy's logs have this format in terminal:-
[TYPE ][CALLER ] Content

And in the log-file, we have:-
[TYPE ]CALLER: Content

To support this, every call to Logger.{info,debug,etc} passes text of this format:-
"CALLER: Content"

This is a duplication of module level info which is already available from name. I feel that it is more useful to use the standard logging.getLogger(name) by default, and that this would provide more information (module hierarchy). Also, other potentially relevant information (especially the timestamp of the call to the log) is missing.

I propose:-

  1. logger.py should set logging.Logger.manager.root = Logger
  2. All instances of msg.split(':', 1) in logger.py be replaced appropriately to use the name of the logger instead. The formatter should also implement the formatTime and formatException methods (this would also require using the logging module's config)
  3. Calls to Logger be replaced with calls to module-specific (or function-specific) logging.getLogger() instances

Benefits:-

  • Contributors need not specify where the logger is being called from
  • Refactoring functions to other locations (rare) would be slightly easier

Cons:-

  • Touches many files in source
  • Probably not possible to maintain identical output as prior to this change

While this seems a relatively simple (if tedious) change, the last con means it items 2 and 3 of this proposal might need to wait for a major release etc. (I think). However item 1 should be trivially do-able, unless I've missed some implications where it would break something.

If this proposal is acceptable I'll try to get a PR up. Point 1 is simple, points 2 and 3 should be do-able without too much effort as well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions