日本ソフトウェア科学会第 38 回大会 (2021 年度) 講演論文集

Typecheck Python Programs and Find Semantic
IdiomsSenxi Li Tetsuro Yamazaki Shigeru Chiba
Researchers have been empirically studying public Python programs to understand how semantic idioms
are used in practice via mining software repositories. In this paper, we propose that the number of codefragments of a semantic idiom can be derived by counting and comparing type errors reported by two different type systems. The proposed method works under a comparison scheme by using two type systems
with variance, typically diﬀerent type kind or typing discipline: The same program can statically typecheckor not, reporting false alarms or not, when enforced by two diﬀerent type systems. The diﬀerent numberof reported false alarms can be viewed as the approximate account of the target semantic idiom. To verify
our statement, we collected 841 Python repositories on Github and investigated the frequency of how adhoc polymorphism is used by using existing type systems with a designed variance. Our empirical study
eﬀectively observed the expected code fragments towards the designed type system variance. Besides, ourtype-based mining approach also discovered some common programming practice which can be found by
traditional methods such as syntactic parsing.

metric. Class inheritance and method overriding

1 Introduction

can also be good candidates.

Researchers have been empirically studying pub-On the other hand, semantic analysis in generallic Python programs to understand how semantic

and static typing in particular have been widely ex-

idioms are used in practice via mining software

plored on the Python programming language withrepositories. Understanding the convention of se-its growing popularity. Researchers have been ex-mantic idioms can help people have a better under-

ploring ways of adding static types to dynamic lan-standing their practical usage and motivates rea-guages [5, 13], providing static guarantees so thatsonable implications to developers for better lan-"well-typed programs cannot go wrong" by reject-

guage designs [3, 7, 15, 16, 19, 32]. A semantic idiom

ing untypeable programs conﬂicting with the de-refers to code fragments that are descriptive by aﬁned type system. While language designers andparticular programming concept. For instance, one

researchers extend a wide variety of type systems

interesting idiom is polymorphism, and even what

to many applications, its combination with reposi-

speciﬁc kind of polymorphism like ad-hoc and para-

tory mining has so far, as far as we know, received
little attention.

∗ Typecheck Python Programs and Find Semantic Id-

ioms
This is an unrefereed paper. Copyrights belong to
the Author(s).
Senxi Li, Tetsuro Yamazaki, Shigeru Chiba, Graduate School of Information Science and Technology,
University of Tokyo.

In this paper, We present that the number ofcode fragments of a semantic idiom can be derived by counting and comparing type errors reported by two diﬀerent type systems. More speciﬁcally, we use two diﬀerent type systems to staticallytypecheck a same program and they deliver diﬀerent number of type errors, respectively. Thus, a2 Semantic Idioms in Python

type system variance can be deliberately designed

A semantic idiom is a code fragment that serves

so that the program can typecheck under a typea single semantic purpose. Finding semantic id-

system with the designed variance if there exists

ioms in dynamic languages like Python is challeng-code fragments written in a particular semantic id-

ing. Yet, understanding the usage of those idioms

iom, and not vice versa. Consequently, the diﬀer-

in production can help developers comprehend theent number of reported errors can approximately

culture of the language and beneﬁt further language

answer the amount of the target code.

designs，which is rather an attracting task in repos-

We be-

itory mining.

lieve that such type-based approach is promising

Here we give an example program which outlines

and practical to achieve repository mining goals.

a typical usage of ad-hoc polymorphism [17, 26],

In summary, this paper ends up to the following

shown in List 1.

contributions:• We propose a type-based approach that canaccomplish repository mining tasks of under-

1
2
3

standing semantic idioms. The method derives
the approximate amount of code written in asemantic idiom by comparing the numbers oftype errors under two diﬀerent, static type systems.

class Person :def __init__ ( self , name ) :self . name = name

4
5
6
7

class Vehicle :def __init__ ( self , name ) :self . name = name8
9
10

• We materialize the proposal with a concrete 11

def getName ( x ) :return x . nametype system variance, union type such that it 12 if input () == ' Person ':13

x = Person ( ' Alice ')can uncover a speciﬁc semantic idiom, ad-hoc 14 else :polymorphism.
• We empirically investigate how ad-hoc polymorphism is used using the concretized methodon collected Python projects.
The remaining of this paper is organized as follows: Section 2 deﬁnes what semantic idioms wewant to survey in repository mining and motivates
the reader by example. Section 3 explains how our
proposed approach recognizes if a semantic idiom
is written in the corpus. Section 4 carries out anempirical study via the proposed method on public
Python repositories. A practical research questionis raised in the empirical study, and we answer thequestion by implementing the method we propose
in Section 3 with a designed, concrete type systemvariance. Section 5 relates our work to proceeding
researches and a brief conclusion ends this paper.

15
16

x = Vehicle ( ' Truck ')getName ( x )Listing 1

Motivating example

The program ﬁrst deﬁnes two classes Person and
Vehicle. A constructor method is deﬁned by setting an instance attribute both called name in themethod body in each of the class deﬁnitions, respectively. It then deﬁnes a function getName whichtakes one single argument. The body of the function searches for an attribute called name, andtreats this attribute as its return. In the main partof the program, a variable x is initialized as either
an instance of class Person or class Vehicle in a
if statement, controlled by a runtime value readfrom the user keyboard. Finally, function getName
deﬁned before is called with the parameter x.

From the perspective of repository mining, one
interesting topic is to empirically investigate thepolymorphic code snippet cannot be proﬁciently
perceived using standard lexical analysis.

usage of ad-hoc polymorphism, which is a proper
instance of the semantic idioms we care in this pa-

3 From a Perspective of Static Semantics

per. In general, the investigation can be answeredby counting the number of functions and meth-

We present that the number of code fragments

ods which are implementations of ad-hoc polymor-of a semantic idiom can be derived by counting

phism. In this example, the answer can be 1, whichand comparing type errors reported by two diﬀerent

points to the function that takes argument of two

type systems. The proposed approach uses static

diﬀerent data types deﬁned at Line 9.

typing under two type systems with variance andUncovering such a semantic idiom in terms ofthey report type errors for untypable code, respec-

repository mining seems not straightforward or

tively. By comparing the number of reported typewidely studied. We believe that one of the rea-errors over the same program, it answers the ap-

sons behind is simply people have not developed aproximate amount of code written in a semantic

proper methodology to fulﬁll the task in dynamic

idiom.

languages. Semantic idioms like ad-hoc polymor-

We begin by discussing standard type inference

phism we quoted are code fragments that serve par-which generates and solves type constraints, andticular semantic purposes. It is inherently notable

reports type errors if the program does not type-that one needs the knowledge of the semantics tocheck under two diﬀerent type systems. Then we

understand its existence in a program. Neverthe-discuss why the designed type systems and theirless, semantic analysis on dynamic languages itself

typechecking results can answer if the program con-is rather complicated, and even worse on large-scale

tains ad-hoc polymorphic code fragment we want toempirical studies.

mine.

Another aspect of the challenge stems from the
dynamic nature of Python. For statically typed

3. 1 Standard Type Inference

programs, a lightweight approach one can conceive

This subsection deﬁnes one of the two type sys-

is a regular lexical analysis used in many MSR re-tems used in our approach to discover ad-hoc poly-

searches. A scenario can go as one parses the source

morphsic code fragments in an informal way. Also,

code and traverses the parsed trees to search typeit brieﬂy explains how a standard type inference

hints such that one can have a superﬁcial under-

works to give types to an untyped program.

standing of semantics of the program. For instance,
functions which arguments are generic-typed (e.g.
in Java) are reasonably parametric polymorphic.
Therefore, one can roughly know the amount of
the semantic idiom written by simply counting thenumber of a speciﬁc kind of types in the program.
While for untyped programs, this handy recipe may
not give us a good taste of the mining purpose as
there is little semantic information from the parsed
syntax tree. As a result, the subsistence of ad-hoc

The core types of the type system is describedas:τ ::= α | β | [id:τ] | τ → ττ ranges over types; α ranges over type variables; βranges over builtin and user deﬁned classes; id denotes method or attribute names; [id:τ ] ranges

over structural types; → denotes function types.
To typecheck untyped programs, one obvious solution is to reconstruct types by type inference. We

attribute name, which is evidently invalid. In cont1 ≤ ["name":

図1

t3 ]

(1)

sequence, the program will be rejected and a typet3 ≤ t2(2)

error is reported as "‘object’ type does not have

Person ≤ t4

(3)

attribute ‘name’" at Line 10 in List 1.

Vehicle ≤ t4(4)

t4 ≤ t1(5)

Generated type constraints from Line 9 to

3. 2 Adding a Type System Variance
Described in the natural language, a type systemvariance is simply the diﬀerence between two type

16 in List 1

systems. A type system is deﬁned by constructors
ﬁrst assign unique type variables for each of theoperated on data types and a set of rules to classify

variables, function parameters and returns. Then

syntactic phrases by their values. So, a type sys-a syntax directed analysis over the program is given

tem variance mentioned in this paper is typicallyto generate type constraints in a subtyping form. A

a single type kind or one syntax directed typing

constraint s ≤ t indicates that s must be a sub-discipline.

type of t. We also use the terminologies to de-

To make the above program typecheck, we add

scribe the constraint such that x is a lower boundunion type as the type system variance to the typeof y and y is a upper bound of x. After that, a se-system described before. Furthermore, we will use

ries of resolution rules are applied to the generated

that type system to infer types for the same pro-type constraints so that constraints are propagatedgram just as we did.

and checked if they admit a solution [22]. During

The type system now is deﬁned as:

the constraint propagation, if there is any incon-τ ::= α | β | [id:sistent constraint, the program is judged untypableand a type error will be signaled. Otherwise, theprogram typechecks and a least restricted solution
is computed from the lower and upper bounds foreach of the type variables [4].

where ∨ ranges over union types. Notice that the
only diﬀerence, or the variance between this typesystem and the previous one is the adaption ofunion type.
Same as the inference process illustrated before,

Back the code example in List 1, we give some of
the type constraints generated by the typing disciplines of the type system, shown in Fig. 1. Parenthetically, function getName is typed as t1 → t2 ;expression x.name has the type t3 ; variable x has
the type t4 .

the type of variable x will be inferred by merging
its two lower bounds. Because the type system now
allows union type which permits multiple primitive
types for a shared instance, x will be inferred as
Person ∨ Vehicle. Since either type of the components of the union holds an "name" attribute, theTo give a closer analysis, the constraint set suggests that t4 should be a supertype of its two lower
bounds Person and Vehicle, which conduces to asolution object (the top class in Python s class hierarchy). While at the same time, it might be notedthat t4 should also be a subtype of ["name":τ] | τ → τ | τ ∨ τt3 ]due to transitive closure from Constraint (1) and(5). That is, t4 , inferred as object, should have antype constraint t4 ≤ ["name":t3 ] is now valid

under the union type system. All the generated
type constraints can be successfully resolved andthe program typechecks.

3. 3 Observation and Discussion

is a concrete implementation of our proposal that

Here a detectable diversity can be observed: atypechecks programs by type systems with a de-diﬀerence between two type systems causes a diﬀer-

signed variance. Particularly, the study implements

ent number of reported type errors. In the example,

union type as the type system variance and gives

the program cannot typecheck with the ﬁrst typeempirical evidence of showing how ad-hoc polymor-

system and a type error is reported. Oppositely,phism is used in practice.

the program, speciﬁcally function getName, type-In the following of this section, we provide ancheck under the second type system which allows

overview of the dataset. Moreover, a comprehen-

union type.

sive report of the study results is presented to an-

We claim that this observation conﬁrms the exis-

swer the raised research question.

tence of ad-hoc polymorphic code fragments in the
program. That is, by counting the diﬀerent number

4. 1 Dataset Overview

of reported type errors from the two type systems,

To build our dataset, we ﬁrst collected 841

one can approximately, but also eﬀectively knows

Python repositories on Github, which containthe number of code fragments written in the se-18,433 Python ﬁles and 1,587,530 lines of code.

mantic idiom.

Those repositories were the top-starred Python

Our proposal works under the following assump-

repositories from the response of the Github Searchtions: type kinds and typing disciplines typicallyAPI. Concurrently, because of the computing lim-

enforce a particular usage of data types and assign

itation of the type inferencer we implemented, we

types to a single kind of syntactic constructions, asnarrowed the searching results by using the searchwell as how programmers commonly implement aqualiﬁer size so that the sizes of all resulting repos-

sematic idiom. Therefore, a type kind or typing

itories are smaller than 5,000 KB.

discipline can be deliberately coined as a variance

We then extracted syntactically valid .py ﬁlesbetween two type systems. Code fragments writ-from each of the collected repositories.

Since

ten in the semantic idiom will not typecheck under

our implementation only supports ﬁles written in

one type system, while the result becomes oppo-

Python 3, we further discarded Python 2 ﬁles,site if the type system variance is turned on. Still,which resulted in 16,324 ﬁles and 1,260,287 LOC.

the typechecking results of some uninterested code

These ﬁles are the exact input to further analysis.

fragments may also alter because of the variance.
We are aware of the fact that our method only tells

4. 2 How Ad-hoc Polymorphism is Used?

the approximate amount of code written in the tar-

By comparing the typechecking results under the

get semantic idiom. Under the insight, we believe

two designed type systems, we ﬁgured out thatthat this proposed semantic analysis is promising

there were 11,100 reported type errors in diﬀerence.

to perform repository mining tasks of uncovering

Since we assume that all the collected public pro-semantic idioms.

grams do not contain any runtime error, we treat

4 A First Attempt: How Ad-hoc Polymorphism is Used?

all detected type errors from our system as false
positives.

In this section, we carry out an empirical study

To provide more details, there were 318,241 num-on a set of collected Python programs from public

ber of reported false positives by the designed typeopen source. The methodology used in the study

system without the variance. On the other hand,4. 3 A Closer Look at Sampled Projects

307,141 errors were reported by the union type system. To defense the eﬀectiveness of our designed

To better investigate whether the designed type

type systems, 171,287 of 318,241, nearly 53.8%, ofsystem variance can successfully discover ad-hoc

all the errors were path resolution failures, whichpolymorphic code, we provide a qualitatively closer

means our tool failed to ﬁnd the path for a module

look of what speciﬁc code fragments are located at

or a missing of third party library. In other word,some of the tested data.

over half of the false positives is not limitation of

We sampled some of the repositories in thethe type system, but rather a matter of implemen-dataset, which were obtained by precisely inspect-tation. Although diﬀerent dataset were involved

ing repositories with the most diﬀerent reported

over studies, the ratio of non-import related errors

type errors by the two designed type systems withfrom our implementation was quite close to thatthe variance. In other words, the following sam-of Rak-amnouykit’s investigation [23] over mainpled repositories are those with the most number

stream Python static checkers Mypy [30] and Py-of ad-hoc polymorphic code snippets suggested bytype [10], which was 54.2% (22,556 of 41,607) ac-

our analysis.
Late Bindings. In convnet-benchmarks †1 , thecording to their qualitative report.
To understand the usage frequency of ad-hoc

union type system typechecks the following piece

polymorphism in the dataset, we further enumerated the numbers of total expressions in all the in-of code:if args . arch == ' alexnet ':import alex
3model = alex . Alex ()diﬀerent number of false positives, the result shows 4 elif args . arch == ' googlenet ':import googlenetthat nearly 0.22% of the expressions were success- 5
6model = googlenet . GoogLeNet ()fully union-typed and used in an ad-hoc polymor7 elif args . arch == ' vgga ':phic manner. A quick interpretation goes as there 8
import vgga
model = vgga . vgga ()is one ad-hoc polymorphic usage for every 450 lines 9
10 elif args . arch == ' overfeat ':of code.
11
import overfeat
model = overfeat . overfeat ()We estimate that this result is quite reasonable to 12
13 else :public Python programs. To give a brief discussion, 14
raise ValueError ( ' Invalidarchitecture name ')we postulate the fact that real-world Python pro15 # ...
grams are semantically easy in terms of data types,
16 model . forward ()put .py ﬁles, which was 5,058,867. By dividing the12

considering its major applications such as machinelearning. It can be easily imaged that functions

In the program, variable model is assigned with in-and methods in those programs typically operate

stances of diﬀerent classes in the if statement con-on particular and single data types. Our results

trolled by an input argument. Alex, GoogLeNet,matches this hypothesis: We found that most of thevgga and overfeat are user deﬁned classes in thefunctions and methods are monomorphic so that

corresponding modules, all of which are derived

they take arguments of single data types based onfrom class Chainer in the deep learning framework
chainer †2 . Each of the classes deﬁnes a method

our type inference result.

forward and the method is invoked after model is†1 https://github.com/soumith/convnet-benchmarks†2 https://chainer.org/

assigned. In our applied type system without unionrs yn c_ s yn c_ o pt s ': ' - avz ' , 'rs yn c_ l is t_ o pt s ': ' -- list - only ' , 'data_store ': ' f p b at t a @ t o m p o u c e .
science . ru . nl ' , ' s u b d i r s _ a s _ d a t a s e t s': False }type, the type of variable model will be inferred asa union of the four types. The message passed to
the variable at Line 16 can be successfully resolved
since each of the type component has the requested

Listing 2

Code in sampled repository

property and thus the program typechecks. On thethe type of the key of the dictionary expression willcontrary, variable model is inferred as type Chainer

be inferred as String under the designed union typeunder the type system without the union type vari-system. Besides, the type of its value will be in-ance. This time a type error is reported when thefered as String ∨ Bool, which is the union of its

message forward is requested since Chainer classall elements. Thus, if one of the values is retrieved

does not deﬁned the method.

by from this dictionary object, a type error will beraised when a massage not shared by the multiple

4. 4 What Are The Other False Positives?

types is passed. Namely,

We believe that false positives that cannot typecheck by the union type system can fairly help dis-1

self . s ou r ce _l o ca ti o n = self . config [ 'data_store '] + ': ' + self . source_dir

cover other semantic idioms in dynamic languages.
where the value of self.config is equal to the

These false positives are assumed not meaninglessvalue of cfg in List 2. Our type system blamed

but rather of valuable indications which can servethat “bad operand for +: Int and String”, while

for mining purposes of discovering Pythonic code

this is an expected behavior of the designed, static

fragments. As a further analysis, we substantiatedtype system though. Similar code snippets that

our claim by sampling and show evidence by con-could not typecheck with our union type system
are also found in QuakeHordes †4 and HelloGitHub

crete examples.
We randomly sampled 58 repositories which con-†5 .

tained 181,444 LOC in the dataset and manually

Reassigning variables with diﬀerent types.

inspected the false positives reported by the union
type system. With further analysis, 5,319 of the er-

common coding pattern that cannot typecheck byrors were errors that failure of resolution of a union

the union type system.

type. We took a closer look at the these places
and inspected the untyped code fragments to ﬁgure out why a union type cannot be successfully
given to the expressions, and to verify if these code

1

2
3
4

fragments match our expectation. We list them incategories below.
Mixed types in containers. This coding exercise
describes elements of diﬀerent data types in container objects such as list and dictionary. As shownin 2 discovered in repository datasets †3 ,1

cfg = { ' rsync_cmd ': ' rsync ' , '†3 https://github.com/fpbattaglia/datasets

Inrepository BeautifulDiscord †6 , we found another5

index = input ( " Discord executable to use( number ) : " )try :index = int ( index )except ValueError as e :print ( ' Invalid index passed ')Variable index is ﬁrst assigned by getting input
from the user. After that, the same variable is reassigned to Int at Line 3 above. Therefore, the typesystem will complain the usage of variable index tothe place where an Int is expected in the program†4 https://github.com/mUogoro/QuakeHordes†5 https://github.com/521xueweihan/HelloGitHub†6 https://github.com/leovoel/BeautifulDiscordlater.

5 Related Works

6 Conclusion

In this section, we will review some of the exist-

In this paper we proposed a type-based approaching studies and make a brief discussion comparing

which can accomplish repository mining tasks ofwith our proposal, respectively.

uncovering semantic idioms.

The proposed ap-

Monat et al. [18] derived a sound, static analysis

proach works by using two diﬀerent type systems

by abstract interpretation by giving Python pro-with designed variance so that program typechecks

grams a concrete semantics, and further taking fullor not while switching the variance. By comparing

control-ﬂow into account such as supporting excep-

the number of reported false alarms, one can derivetion handling and expressing parametric polymor-

the approximate amount of code that is written inphism. Compared with their work of performing

the corresponding semantic idiom.

static analysis by structural induction on the syn-

We carried out an empirical study over 841 pub-tax, our proposal applies a standard static typelic Python repositories to investigate common pro-checking, which is generally ﬂow-insensitive andgramming idioms. Our approach successfully de-context-insensitive, with a constraint-based type

tected the usage frequency of ad-hoc polymor-

inference for dynamically typed programs.

Fur-phism, but also it uncovered some well-known

thermore, our approach performs repository mining

coding practice that can be found by traditionaltasks by carefully designing several, diﬀerent type

methods like syntactic parsing. Thus, we believesystems and uncovering a semantic idiom with thethat such typed-based method is an eﬀective andcorresponding type system variance.

promising approach to performing repository min-Rak-amnouykit et al. [23] did an empirical sytudy

ing tasks.

of how Python developers use type annotations
with PEP484 [30], and evaluated the performance

参 考 文 献of Mypy [14] and Pytype [10] on public Github[ 1 ] Akbar, S. A. and Kak, A. C.: A Large-Scale
Comparative Evaluation of IR-Based Tools for Bug
Localization, Proceedings of the 17th International
Conference on Mining Software Repositories, MSR’20, New York, NY, USA, Association for Computing Machinery, 2020, pp. 21–31.
[ 2 ] Allamanis, M. and Sutton, C.: Mining Idioms
from Source Code, Proceedings of the 22nd ACM
SIGSOFT International Symposium on Foundations of Software Engineering, FSE 2014, New
York, NY, USA, Association for Computing Machinery, 2014, pp. 472–483.
[ 3 ] Amanatidis, T. and Chatzigeorgiou, A.: Studying the evolution of PHP web applications, Information and Software Technology, Vol. 72(2016),
pp. 48–67.
[ 4 ] An, J.-h. D., Chaudhuri, A., Foster, J. S., andHicks, M.: Dynamic Inference of Static Types
for Ruby, SIGPLAN Not., Vol. 46, No. 1(2011),
pp. 459–472.
[ 5 ] Aycock, J.: Aggressive Type Inference, November 1999.
[ 6 ] Cousot, P.: Types as Abstract Interpretations,
Proceedings of the 24th ACM SIGPLAN-SIGACT

repositories. Mypy and Pytype are two of the celebrated tools of performing static type checking andinference for Python programs. The authors explored that programs with type annotations rarely
typecheck by the existing tools: both of them exhibit false positives and also useful errors. From the
aspect of empirically studying open source Python
repositories, our work also enforces type systems tostatically typecheck Python programs. Conversely,
we oﬀer our own implementation so that we caneasily apply and manage diﬀerent type systems todiscover semantic idioms. Besides, reported false
positives are viewed as indication of the target codefragments suggested by the designed variance of
two type systems.

Symposium on Principles of Programming Languages, POPL ’97, New York, NY, USA, Association for Computing Machinery, 1997, pp. 316–331.
[ 7 ] Dyer, R., Rajan, H., Nguyen, H. A., andNguyen, T. N.: Mining Billions of AST Nodes toStudy Actual and Potential Usage of Java Language Features, Proceedings of the 36th International Conference on Software Engineering, ICSE
2014, New York, NY, USA, Association for Computing Machinery, 2014, pp. 779–790.
[ 8 ] Garcia, R., Clark, A. M., and Tanter, E.: Abstracting Gradual Typing, Proceedings of the 43rd
Annual ACM SIGPLAN-SIGACT Symposium on
Principles of Programming Languages, POPL ’16,
New York, NY, USA, Association for Computing
Machinery, 2016, pp. 429–442.
[ 9 ] github: octoverse, May 2020.
[10] google: pytype, May 2016.
[11] Guido van Rossum, Barry Warsaw, N. C.: PEP
8 – Style Guide for Python Code, July 2001.
[12] Kagdi, H., Collard, M. L., and Maletic, J. I.:
A Survey and Taxonomy of Approaches for Mining Software Repositories in the Context of Software Evolution, J. Softw. Maint. Evol., Vol. 19,
No. 2(2007), pp. 77–131.
[13] Kazerounian, M., Ren, B. M., and Foster, J. S.:
Sound, Heuristic Type Annotation Inference for
Ruby, Proceedings of the 16th ACM SIGPLAN
International Symposium on Dynamic Languages,
DLS 2020, New York, NY, USA, Association for
Computing Machinery, 2020, pp. 112–125.
[14] Lehtosalo, J., van Rossum, G., and Levkivskyi,
I.: mypy, June 2012.
[15] Marcilio, D. and Furia, C. A.: How Java
Programmers Test Exceptional Behavior, 2021
IEEE/ACM 18th International Conference on Mining Software Repositories (MSR), 2021, pp. 207–
218.
[16] Mazinanian, D., Ketkar, A., Tsantalis, N., andDig, D.: Understanding the Use of Lambda Expressions in Java, Proc. ACM Program. Lang., Vol. 1,
No. OOPSLA(2017).
[17] Milner, R.: A theory of type polymorphism inprogramming, Journal of Computer and System
Sciences, Vol. 17, No. 3(1978), pp. 348–375.
[18] Monat, R., Ouadjaout, A., and Miné, A.:
Static Type Analysis by Abstract Interpretationof Python Programs, 34th European Conference
on Object-Oriented Programming (ECOOP 2020),
Hirschfeld, R. and Pape, T.(eds.), Leibniz International Proceedings in Informatics (LIPIcs),
Vol. 166, Dagstuhl, Germany, Schloss Dagstuhl–
Leibniz-Zentrum für Informatik, 2020, pp. 17:1–
17:29.
[19] Nakamaru, T., Matsunaga, T., Yamazaki, T.,

Akiyama, S., and Chiba, S.: An Empirical Studyof Method Chaining in Java, Proceedings of the
17th International Conference on Mining Software
Repositories, MSR ’20, New York, NY, USA, Association for Computing Machinery, 2020, pp. 93–102.
[20] Oracle: JDK 5.0 Documentation, September
2004.
[21] Oracle: Java Platform, Standard Edition 8 API
Speciﬁcation, March 2014.
[22] Pottier, F.: A Framework for Type Inference with Subtyping, SIGPLAN Not., Vol. 34,
No. 1(1998), pp. 228–238.
[23] Rak-amnouykit, I., McCrevan, D., Milanova, A.,
Hirzel, M., and Dolby, J.: Python 3 Types in the
Wild: A Tale of Two Type Systems, Proceedings ofthe 16th ACM SIGPLAN International Symposium
on Dynamic Languages, DLS 2020, New York, NY,
USA, Association for Computing Machinery, 2020,
pp. 57–70.
[24] Siek, J. and Taha, W.: Gradual Typing for Objects, ECOOP 2007 – Object-Oriented Programming, Ernst, E.(ed.), Berlin, Heidelberg, Springer
Berlin Heidelberg, 2007, pp. 2–27.
[25] Siek, J. G. and Taha, W.: Gradual Typing for
Functional Languages, IN SCHEME AND FUNCTIONAL PROGRAMMING WORKSHOP, 2006,
pp. 81–92.
[26] Strachey, C.: Fundamental Concepts in Programming Languages, August 1967.
[27] Thatte, S.: Quasi-Static Typing, Proceedings ofthe 17th ACM SIGPLAN-SIGACT Symposium on
Principles of Programming Languages, POPL ’90,
New York, NY, USA, Association for Computing
Machinery, 1989, pp. 367–381.
[28] Tobin-Hochstadt, S. and Felleisen, M.: Interlanguage Migration: From Scripts to Programs, Companion to the 21st ACM SIGPLAN Symposium on
Object-Oriented Programming Systems, Languages,
and Applications, OOPSLA ’06, New York, NY,
USA, Association for Computing Machinery, 2006,
pp. 964–974.
[29] Turnu, I., Concas, G., Marchesi, M., Pinna, S.,
and Tonelli, R.: A modiﬁed Yule process to model
the evolution of some object-oriented system properties, Information Sciences, Vol. 181, No. 4(2011),
pp. 883–902.
[30] van Rossum, G., Lehtosalo, J., and Langa, L.:
PEP 484 – Type Hints, September 2014.
[31] Zapponi, C.: GitHut, May 2014.
[32] Zhai, H., Casalnuovo, C., and Devanbu,
P. T.: Test Coverage in Python Programs, 2019
IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), (2019), pp. 116–120.