Leave all the heavy-lifting to AI but we need to know how it is designed and structured. For example in this portfolio_analysis_display module,

The configuration system was designed with these considerations:

Security: Sensitive values like API keys can be provided via environment variables instead of being committed to code

Separation of concerns: Configuration is completely separated from application logic

12-Factor App principles: Following modern application configuration best practices

Developer experience: Simple API with intuitive methods (get, set, save)

Operational flexibility: Easy to configure in development, testing, and production environments

For a financial application like Portfolio Analysis Display, the logging system was designed with these specific considerations:

1. Audit Trail: Financial applications require comprehensive logging for auditing and compliance
2. Troubleshooting: Detailed logs help diagnose issues with market data, calculations, and portfolio operations
3. Performance Monitoring: Timestamps in logs help identify performance bottlenecks
4. Security: Separate log files help with security reviews and incident response
5. Data Integrity: Logs provide a record of data processing for verification

1. Centralized Configuration

The setup_logger() function provides a single point of configuration for all logging across the application. This ensures:

• Consistent logging format across all modules
• Centralized control over log levels
• Easy modification of logging behavior without changing application code

2. Multiple Output Destinations

The logger is designed to output to both:

• Console (for immediate feedback during development and operation)
• Rotating log files (for persistent records and troubleshooting)

This dual-output approach ensures that logs are both visible during operation and preserved for later analysis.

3. Log Rotation

The implementation uses RotatingFileHandler with specific parameters.

4. Different Formatting for Different Contexts

The logger uses two distinct formatters:

• Detailed formatter for file logs: %(asctime)s - %(name)s - %(levelname)s - %(message)s
• Simple formatter for console: %(levelname)s: %(message)s

This provides comprehensive information in log files while keeping console output clean and readable.

5. Environment-Aware Configuration

The log level can be configured through:

• Function parameters (for programmatic control)
• Environment variables (for deployment configuration)
• Default fallback to ‘INFO’ (for sensible default behavior)

6. Automatic Directory Creation

The logger automatically creates the log directory if it doesn’t exist

8. Timestamp-Based Log Files

Log files are automatically named with the current date:

there are five level of logging, debug, info, warning, error and critical, in logging.basicConfig(level=logging.INFO, format=’%(asctime)s – %(levelname)s – %(name)s: %(message)s’) or as in Tim’s example basicConfig(evel=logging.INFO, filename=”log.log”, filemode=”w”)