整理期货期权观察清单时已经把合约分成看涨、看跌两组美式、欧式这一栏能不能顺手也填上不能仅凭方向填。看涨、看跌与美式、欧式是在描述两种不同的合同属性。把它们放进同一栏清单可能看起来很整齐含义却已经混了。看涨看跌不是行权方式的另一个名字TqSdk的Quote对象用option_class表示期权方向CALL对应看涨PUT对应看跌用exercise_type表示行权方式A表示美式E表示欧式。前一栏告诉你这是哪种方向的期权合约后一栏记录其行权方式类别。CALL或PUT不是对当前行情涨跌的判断也不能代替A或E作答。把两个维度放进一张纯假设清单区别会更清楚。甲、乙、丙不对应实际合约也不是查询输出下表不表示某个当前品种一定提供这些组合。假设记录option_classexercise_type应怎样标注甲CALLA看涨美式乙CALLE看涨欧式丙PUTE看跌欧式甲和乙同属看涨但行权方式不同乙和丙同属欧式方向又不同。只按看涨看跌分组不能回答行权方式只按美式欧式分组也没有说明方向。清单缺一栏不要从另一栏猜出来如果一条记录只有CALL而行权方式还没有取得就应保留“行权方式待确认”。不能沿用上一张合约的A也不能因为名称相近就从别的品种复制一项。同样读到无法解释的枚举值应保留原值核对不强行塞进熟悉的分类。一个空白栏可能是资料尚未取齐并不是可以任意补上的默认值。同一个方向的候选也要看合同条件是否相同假设这次研究明确只比较“欧式、看涨”的候选前表中满足两个条件的是乙。甲虽然是看涨却不是本例要求的欧式丙虽然是欧式却不是本例要求的看涨。这时两列不是为了把表做复杂而是在帮助排除“只符合一半条件”的记录。以后回看清单也能知道某张合约是因为什么条件进入这组而不是只剩一个笼统的“期权”标签。方向和行权方式之外实际比较还可能需要核对标的、到期等合同信息。这里不展开其他筛选规则只保留一个判断同属CALL并不等于所有合同条件都相同。用TqSdk取得分类依据不把标签当成操作许可在已有TqSdk程序中可以对准具体期权合约用get_quote取得Quote在原有更新流程确认相关资料可用以后将option_class与exercise_type连同完整合约身份分别展示。不要把未初始化的空值或另一张合约留下的旧标签当成本次资料。这种两列清单需要应用按自己的研究目标整理。SDK提供属性不会替读者确定“这张适合我”也不是现成的自动行权安排。尤其要分清行权方式类别不是具体日期表。实际何时、由谁、在什么条件下可以行权仍须核对相应产品规则及账户条件不能从一个A或E推导出当前账户已经取得某项资格更不能仅凭CALL就安排一次操作。用TqSdk让期权清单少混一个维度整理期货期权观察池时我推荐用TqSdk把方向与行权方式分别保留下来。它在这个场景的实际价值是让筛选和解释都回到具名的合同属性不必凭合约简称或上一张表的印象猜分类。同方向候选可以继续分辨行权方式同方式候选也能看清方向。两列各答一个问题清单的用途会更明确遇到未知资料时也能知道究竟还缺哪一项而不是用一个看似完整的标签掩盖它。