基于上下文分析的 Python 实时 API 推荐

原文来自微信公众号“编程语言Lab”：基于上下文分析的 Python 实时 API 推荐
搜索关注 “编程语言Lab”公众号（HW-PLLab）获取更多技术内容！
欢迎加入 编程语言社区 SIG-程序分析 参与交流讨论（加入方式：添加文末小助手微信，备注“加入 SIG-程序分析”）。

作者 | 何欣程

编辑 | Skylar

作者简介

何欣程，南京大学计算机系软件质量研究所博士生，研究方向为程序分析，编程辅助。

视频回顾

编程语言技术沙龙｜第16期：基于上下文分析的 python 实时 API 推荐

1 研究介绍

API 推荐一直是一个热门话题，相关的工作 ¹ 也很多。当前的 API 推荐主要分为两类，一类是基于自然语言查询的 API 推荐，这类工作更加关注自然语言文本相关信息，像众包信息和 API 文档等。例如 16 年的 RACK，通过从 Stack Overflow 的众包知识中提取关键词 - API 映射提供相关 API 列表推荐。18 年的 BIKER 通过 word embedding 方法计算两段文本描述的相似度，根据 Stack Overflow 文本和 API 文档的相似度进行排序。

相比来说，基于代码上下文的 API 推荐在实际开发过程中使用更多的一般都是各大语言 IDE 中的智能代码补全插件，这类插件就涵盖了比较全面的 API 推荐功能，比如基于 Typeshed 的 Pycharm 补全功能以及 Vscode Intelli 系列的智能插件等等。

在论文方面，基于代码的 API 推荐更多的是应用在静态语言上，例如 Java，C，C++ 等，但针对动态语言的较少一些。关于 Python 的一共有三篇，其中两篇都是利用 AST 信息来进行学习决策。但在实时场景下，Python Parser 并不能解析出可用的 AST，这就在 IDE 等场景下，给具体的落地应用带来挑战。

2 实时场景下的 API 推荐

目标与挑战

基于这个问题，我们就尝试暂时从 AST 上挪开视线，提出一种利用如 Tokenflow、Dataflow 等上下文信息来进行实时 Python API 推荐的方法。具体来说，实时场景下的 API 推荐，我们将其定义为，针对形如 caller.API 的 recommendation hole，我们在仅知 hole 之前的代码情况下，提供排序后的 API 候选表。

而要达成这个目标，需要解决两方面的挑战。首先，是 Python 本身的动态特性。Python 具有类型动态性、路径敏感性，传统的静态分析方法在上面要么失败要么难以得到足够精准的结果。其次，在实时场景下，代码的语法语义都不完整，给静态程序分析带来很大难题，缺乏代码开发历史，针对一些基于历史变更学习的方法带来挑战。此外，实时性推荐也需要一些在线的轻量级的分析过程。

Visual Studio IntelliCode 的局限性

面对这些挑战，基于学习的 API 推荐方法往往比大多数传统方法具有更好的性能。然而，它们也有一些局限性。Visual Studio IntelliCode 是最先进的 Python 推荐工具之一。它是以学习为基础的。我们使用它来演示这种方法的一些局限性。

首先，推荐 API 的能力很大程度上依赖于 API 调用对象的类型推断结果。例如，当调用方类型未知时，没有可收集的候选 API。Intellicode 对推荐点 kwargs 产生 NULL 推荐。原因是它不能推断调用者对象的类型。

其次，即使可以成功推断对象类型，Intellicode 生成的推荐列表也有可能只包含字母顺序的候选对象。主要原因是基于学习的方法在推荐频繁调用的 API 方面做得很好，而不是项目特定的 API。

另外，即使 IntelliCode 成功地推荐了一些被标记为星号的候选人，这些推荐也可能是错误的。在例子中， IntelliCode 提供星号标记的 API，但排名前 4 的答案都不正确，但可能在训练集中使用频率更高。这个问题的产生部分是由于机器学习的不确定性。

PyART——从不完整的 Python 上下文中提取数据流

PyART 提供了一种从不完整的 Python 上下文中提取数据流的有效方法，我们称它为乐观的，因为这样的数据流既不 sound 也不 complete，但足以提供 API 建议，收集起来也具有成本效益。核心思想是模拟人类直觉，这与传统的数据流分析不同。传统的数据流分析试图在基本块的边界上获取过程中每个点的信息，并限定每个块的进入状态和退出状态。控制流用于确定一个值如何传播。然而这对于 Python 来说是困难的。

相比之下，人类主要基于局部符号信息来推断数据流。例如，他们考虑周围的变量和代码结构。因此，PyART 定义了从五个基本抽象语法单元派生近似数据流的规则。

Rule1: Assignment

规则 1 是对赋值做了一个约束，对于位于位置 l 之前的右侧操作数 e 中的任何变量和方法对象 u，都有数据流从 u 流向左侧操作数 v。这里，标识符 VM 表示表达式中的所有变量和方法对象，DFS(v) 表示涉及对象 v 的所有数据流路径。

Rule2: Loop

规则 2 是循环指定数据流提取，即从迭代器 e 到循环变量 v 中的任何变量或方法对象中有数据流流向。

Rule3: Object attribute access/invocation

规则 3 是关于属性加载和调用的，如果一个对象 u 访问了一个字段属性或调用了一个方法属性 v，在 u 和 v.n 之间有数据流。

Rule4: Container access

规则 4 是为容器访问指定了数据流，如果容器 v 通过索引 e 访问，则数据流从 e 中的任何对象 u 到容器对象 v。

Rule5: Function parameter passing

规则 5 是用于函数参数传递，它指定任何参数 e 中涉及的任何变量都有数据流流向函数 f。

Rule6: Function parameter passing

由于这五个单元可能以组合的形式出现，所以规则 6 聚合了从单个单元派生的数据流关系。

Rule7: Propagation

此外，PyART 根据传播规则对流的效果进行建模。例如，如果 line1 中有一个关于 x 的数据流，它将在 line1 之后关于 x 的其他位置传播。

Rule8: Preservation

最后，规则 8 保留所有变量或方法对象不受单位影响的数据流关系 (因此应该删除)。

编码器根据收集到的特征，生成一个包含四个元素的特征向量，包括：数据流提示，token 相似性、caller-API 共现频率以及上下文 token-API 共现频率。在训练过程中，模型构造器使用随机森林进行监督学习。

实验评估结果表明，我们提出的数据流分析方法、API 推荐方法均优于 baseline，且具有轻量级、实时性的优势。

---

1. Peng Y, Li S, Gu W, et al, Revisiting, Benchmarking and Exploring API Recommendation: How Far Are We?[J]. arXiv preprint arXiv:2112.12653, 2021. ↩︎