画大饼

重要

随时变更，不一定实现！ (并非真正的待办列表，准确来说这应该是想法列表)

实现CLIArgSL

传入一个命令行解析器，调用其以获取ABCConfigData，保证高度自定义

添加类似SwitchSL来做到同命名空间不同配置无缝切换

提供switch方法和一个元文件以记忆(数据驱动) 注意！应实现一个特殊ConfigFile以允许switch操作

命名空间使用专门的NameSpace类管理

提供ABCNameSpace声明基础接口 具体实现为PathNameSpace 提供 '/' 操作符链接，支持str 通过属性快速获得ext 或许应该先做一个单独注册库用于处理灵活的注册，太多地方用得上了

实现DocumentSL以从文档中提取配置数据

备注

已有测试性实现

通过re+py3.14 t-string匹配以从任意字符串(如文档文件)中 提取并验证配置数据 检查版本并抛出DependencyNotFoundError("python>=3.14", False)

加载行为：re.search | re.findall | re.match | re.fullmatch 保存行为：re.sub

ConfigPool.stored,destroy,purge方法操作文件

SL提供destroy以移除文件 SL提供purge以静默移除文件（不存在时不进行报错） SL提供stored以检查文件存在

采用watchdog库实现ConfigPool当文件/目录变更时自动重载

或许可以考虑在get时检查是否更新，为了避免性能问题添加防抖， 但是这会造成数据同步问题，可能代码的其他部分尚未获取最新配置

ConfigRequirementDecorator

默认动态调用load而不是仅在初始化时调用 提供参数file_cacher

优化文档SEO

让zread.ai或deepwiki.com试试

SetConfigData与完善StringConfigData的UserSting接口支持

...

实现VersionedSL继承自SwitchSL

提供release方法fulldump当前配置数据 注意！release方法应实现在特殊ConfigFile上 需要特殊ConfigData来计算差异并自动/手动生成版本号 可能功能？实现BackupSL但是目前好像用VersionedSL就足够了

MergedConfigData以自动合并成员list/dict/set

实现对应SL 或许可以考虑将meta和member都拆分到ABC类后多继承，然后实现一个 BasicComponentConfigData实现基础的 元-成员 映射并提供 _member方法获取成员

ConfigPool.require

如果未传入validator那么则 完全无认证（返回原始数据），根据validator类型选择validatorfactory ValidatorTypes.DEFAULT不再为None而是实际名称，改为StrEnum

DefaultValidatorFactory重命名为PythonicValidatorFactory

记得更新相关文档和Enum

ABCSLProcessorPool

更改为ABCRegistry，并不再被ABCConfigPool继承而是组合 所有的信息通过注册表存储，ConfigPool持有一个ROOTRegistry 其他所有信息通过注册表中的注册表注册 注意使用Supplier接口实现懒加载

将验证器系统改为滤镜系统，以支持动态插值

同时记得改名validator为schema滤镜通过一个注册表生效，每个滤镜都需要注册到一个统一注册表中

(ConfigPool在注册表重构后变成ConfigManager?)

通过一个Builder从元数据从注册表中提取构建一个对象，假设该对象实现 了目标接口后使用参数”初始化“(可能为闭包函数)，或许可以考虑对外保留 现有的(schema, filter) -> Any接口，内部转换为 Builder({"filter": filter, "schema": schema})(或许是dataclass)

(!PipeLine/Workflow名称待定)来提供对外后续考虑的PipLineSL的meta数据驱动原生支持 除了普通的滤镜外提供一个PipLine滤镜其接受一个filters: list[(构建子滤镜的必须数据 例如filter与cshema字段)]列表，以及一些额外参数决定行为 额外参数可以通过一个注册表控制自定义行为 例如多线程并行所含滤镜(但是这太重了，如果后续考虑把注册表系统和一些 实用方法作为单独包发布的时候再说吧)或者对于所有子滤镜控制执行顺序(但是更用不 上了，这些如果将数据滤镜系统作为单独包发布再说)之类的 使用Context携带一些额外数据

考虑使用之前考虑的注册表系统提供最大灵活性向下文提供数据 (或许考虑携带builder和manager(或遵循最小接口原则manager只提供其中的registry?)以供PipLine使用) 至少内置history: list(deque?自定义对象？)[*Data]属性，但是是否向里面 推送数据由目标处理器自己决定，这意味着滤镜可以不但不产生数据反而 可以消耗数据，history[-1]则固定语义为current_data，找不到就由外层 PipLine作为Wrapper决定行为

另外，目前的滤镜系统仅支持ConfigData非ConfigFile，但是如果提升到 ConfigFile会导致没有那么“纯粹”，文件和数据的复杂程度不在一个量级 这么搞的话就更重了

总而言之，好像太重了没必要 不过这玩意确实方便和通用，有好多地方用得上，可以考虑做一个单独库

新增CustomPiplineSL通过元数据自定义配置数据后处理

(滤镜系统)

补充IndexKey的负索引测试在SequenceConfigData

...

添加MultiFormatSL以支持多重格式配置

构造参数传入字典/SL处理器实例列表动态获取文件后缀和注册名 配置池中固定采用.multi或.multi.format后缀以表示 实际存储后缀优先级： 指定的.multi.format -> ConfigFile附带格式(上次格式) -> 构造参数声明支持的格式 好像没必要，配置池本来就能根据文件后缀推导格式，加这个多此一举，直接通过文件后缀区分就行了要不然又引入一堆问题

可以考虑添加一个I18NData/I18NSL来为一些项目集成简易的translatekey+f-string的i18n

...

添加一个CustomSL，几乎允许用户通过参数完全自定义

以简化一些地方的自定义成本，（回调函数处理SL）

考虑添加README描述进一步声明项目还致力于最大程度保留元信息

deepcopy还是太多了必须得清

至少configpool的__getitem__得清

添加dump功能（CLI），根据schema生成类型注解完善的项目模板（或文件

避免手动编写后处理逻辑，并进一步减少模板代码

使用singledispatch替代ConfigDataFactory及其内部的懒加载逻辑

...

添加README声明可以“一次学习，处处使用”

声明口号含义为：适用于需求频繁变更无需大规模改动（如配置格式切换

经验可迁移（下一个项目低学习成本

添加示例和详细文档说明如何几乎不影响无关业务代码的情况下切换格式/新项目低学习成本

添加一个用于格式迁移的SL处理器

当一个文件被读取时优先读取旧格式，写入时写入新格式并删除旧格式配置做到无缝迁移