No more prints #1373

New Issue

2018-10-12T09:40:46+02:00

PeterSurda commented

2018-10-12 09:40:46 +02:00

(Migrated from github.com)

There are still occasions where print has remained and should be replaced by the logger.*. Some can remain, e.g. the notification about daemonizing or missing dependencies. This issue will be updated as I find more locations.

src/api.py

There are still occasions where `print` has remained and should be replaced by the `logger.*`. Some can remain, e.g. the notification about daemonizing or missing dependencies. This issue will be updated as I find more locations. - [x] `src/api.py`

coffeedogs commented

2018-10-19 17:30:32 +02:00

(Migrated from github.com)

@PeterSurda can we be clear about scope and expected results please? Some thoughts that come to mind:

Increase scope to use the opportunity of going through the code thoroughly with a mind on logging
Test various logging configurations (which?), remove config cruft, document what to expect out of logging, maybe testing further logging config examples (rsyslog, elasticsearch?)
Ensure log levels are appropriate and sent to stdout/stderr as appropriate
Consider consolidating the number of log levels in use
Consider any refactoring or standardisation of logging code (e.g. avoid code repetition, circular imports)
Consider whether a log entry is actually required; maybe the point of a log entry is to watch out for a condition that better testing could have guarded against
Ensure consistent log message style (tenses, first/third sing/pl person etc.)
Change print statements to use the logger
Implement tests around logging (critical examples?)

Quick check of the scale of this task:
12 logger.exception() calls
12 logger.fatal() calls
13 logger.critical() calls
20 logger.warning() calls
167 logger.info() calls
185 logger.debug() calls
467 (approx) print statements

@PeterSurda can we be clear about scope and expected results please? Some thoughts that come to mind: * Increase scope to use the opportunity of going through the code thoroughly with a mind on logging * Test various logging configurations (which?), remove config cruft, document what to expect out of logging, maybe testing further logging config examples (rsyslog, elasticsearch?) * Ensure log levels are appropriate and sent to stdout/stderr as appropriate * Consider consolidating the number of log levels in use * Consider any refactoring or standardisation of logging code (e.g. avoid code repetition, circular imports) * Consider whether a log entry is actually required; maybe the point of a log entry is to watch out for a condition that better testing could have guarded against * Ensure consistent log message style (tenses, first/third sing/pl person etc.) * Change print statements to use the logger * Implement tests around logging (critical examples?) Quick check of the scale of this task: 12 `logger.exception()` calls 12 `logger.fatal()` calls 13 `logger.critical()` calls 20 `logger.warning()` calls 167 `logger.info()` calls 185 `logger.debug()` calls 467 (approx) `print` statements

navjotcis commented

2020-09-22 15:54:08 +02:00

(Migrated from github.com)

I have removed the print statement of the api.py module.
https://github.com/Bitmessage/PyBitmessage/pull/1673

I have removed the print statement of the api.py module. https://github.com/Bitmessage/PyBitmessage/pull/1673

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2025-02-27#1373