Problem
KnowledgeBase has two KI registration paths: the direct API (ask_ki, answer_ki, post_ki, react_ki, ki_from_info) and the settings path (ki_from_settings, ki_from_settings_with_default_handler). The settings path keeps a private _build_settings reference and guards every call with if not self._build_settings: raise ValueError(...).
This mixes two concerns: the KB's runtime identity/behaviour, and its build-time configuration source. KnowledgeBase as a concept shouldn't know about KnowledgeBaseSettings.
Proposed solution
Extract settings-based KI registration into a thin KnowledgeBaseBuilder (or a KnowledgeBase subclass) that holds the settings reference and exposes ki_from_settings. KnowledgeBase.from_settings() returns this builder/subclass. The base KnowledgeBase has no _build_settings field and no settings-guarded methods.
Benefits
KnowledgeBase is testable without any settings knowledge.
- The settings-path code concentrates in the builder (locality).
- Callers who don't use settings never see those methods in autocomplete.
Problem
KnowledgeBasehas two KI registration paths: the direct API (ask_ki,answer_ki,post_ki,react_ki,ki_from_info) and the settings path (ki_from_settings,ki_from_settings_with_default_handler). The settings path keeps a private_build_settingsreference and guards every call withif not self._build_settings: raise ValueError(...).This mixes two concerns: the KB's runtime identity/behaviour, and its build-time configuration source.
KnowledgeBaseas a concept shouldn't know aboutKnowledgeBaseSettings.Proposed solution
Extract settings-based KI registration into a thin
KnowledgeBaseBuilder(or aKnowledgeBasesubclass) that holds the settings reference and exposeski_from_settings.KnowledgeBase.from_settings()returns this builder/subclass. The baseKnowledgeBasehas no_build_settingsfield and no settings-guarded methods.Benefits
KnowledgeBaseis testable without any settings knowledge.