Feature: Improving Context to handle Assertions and Logging differently depending on the context.

[guillaume-chevalier]

Is your feature request related to a problem? Please describe. Problems:

• When writing code, it's good to do lots of assertions and error messages. It improves development time as errors are catched quickly in unit tests, instead of requiring debugging later on. However, we may want to disable some assertions in production environment.
• For the logger, we may want to pass a different logger in production than in unit testing.

Describe the solution you'd like

• We should have a BaseAssertion class or something from which we can inherit and pass to the context. The context would use a default and predefined Assertion class if it is not specified so as to make things simple for non-advanced users.
• Same for the logger. We could have a BaseLogger and a DefaultConsoleLogger implementing the BaseLogger. This logger would be used by the context when creating the context if no specific logger is passed.

Note that upon failing an assertion, the Asserter would need to get the logger in the context to log the failure as well. This means that despite the Asserter is in the Context, the Asserter needs to be passed the context when asserting so as to be able to fetch the Logger of the context. This means that the Logger is probably a service with a predefined service Key string (e.g.: context.get_service("logger").

Overall, the context seems to need some basic services at all times, and for ensuring consistency of the code and proper interdependency of the services, some services seem to require some predefined keys. I do not have ideas of alternatives for this idea, and I would like to find a better solution than to use predefined reserved keys.

FYI @vincent-antaki

[vincent-antaki]

I agree with this except the part where we use keys to access services which are there by default. I'd rather have these services as attribute of the context since they are not optional anyway.

[guillaume-chevalier]

• class Logger in Neuraxle could be useful. For instance: Logger.get_default_logger(), or Logger.from_raw_logger(logger)
• BaseLogger and a DefaultConsoleLogger
• The Logger is probably a service with a predefined service Key string (e.g.: context.get_service("logger")
• Predefined keys in the context's services similar to programming languages' reserved keywords or preexisting keywords. See #516.