I wonder whether the authors consider "value = somedict.get('somekey')" or "match_object = re.search(pattern, somestring)" as returning a single type. Both of those common calls can return None.
I'm also curious as to what they consider "unbounded polymorphism". Calls like "len(s)" or "with cm" or "for x in s" work with many different types (though usually only on one type at a particular part of a program). Likewise, most of the collections types and classes are necessary generic (in one place you make make a set of integers and in another place you use a set of strings). The use of the collections is typically monomorphic but the collections themselves are necessarily generic.
Another thought is that when I write programs that use a single type for a given variable, I still place value on the duck-typing and polymorphism (to ease future maintenance, support debugging, and leave the code loosely coupled). For example, when I write a function that accepts a file object and the calling code only passes in file objects, I still value my ability to pass in a StringIO object instead.
Another thought is that I find the mechanical extraction of percent usage statistics to be dubious since the results are profoundly biased by the kind of code being sampled. For example, my data analytics code is nearly 100% monomorphic. However, code that uses ORMs like SQLAlchemy, Peewee, or Django or that uses templating engines (like Jinga2, Cheetah), or that does anything interesting would tend to have much different statistics. (Performance Guided Optimization in C has taught us that data and usage patterns greatly affect the statistics).
All that said, I don't disagree with the authors that a lot of Python code could be statically typed. Tracing JITs have already proven the value of call site specialization to a particular type.
> I wonder whether the authors consider "value = somedict.get('somekey')" or "match_object = re.search(pattern, somestring)" as returning a single type. Both of those common calls can return None.
val get: 'a dict -> 'a -> 'b option
val search: re -> string -> match option
Above is an hypotetical type notation in OCaml for both functions. I think it pretty much covers everything.
I understood "unbounded polymorphism" to mean that for a given variable, it took on values whose types do not follow any structural rules. Your example with file objects and StringIO objects would not fall in that category, because their relationship could be modeled with single inheritance. (One from the other; both from a parent; both implementing an interface.) Nor would 'len(s)' be unbounded, because 'len' could be modeled as parametric polymorphism.
I'm also curious as to what they consider "unbounded polymorphism". Calls like "len(s)" or "with cm" or "for x in s" work with many different types (though usually only on one type at a particular part of a program). Likewise, most of the collections types and classes are necessary generic (in one place you make make a set of integers and in another place you use a set of strings). The use of the collections is typically monomorphic but the collections themselves are necessarily generic.
Another thought is that when I write programs that use a single type for a given variable, I still place value on the duck-typing and polymorphism (to ease future maintenance, support debugging, and leave the code loosely coupled). For example, when I write a function that accepts a file object and the calling code only passes in file objects, I still value my ability to pass in a StringIO object instead.
Another thought is that I find the mechanical extraction of percent usage statistics to be dubious since the results are profoundly biased by the kind of code being sampled. For example, my data analytics code is nearly 100% monomorphic. However, code that uses ORMs like SQLAlchemy, Peewee, or Django or that uses templating engines (like Jinga2, Cheetah), or that does anything interesting would tend to have much different statistics. (Performance Guided Optimization in C has taught us that data and usage patterns greatly affect the statistics).
All that said, I don't disagree with the authors that a lot of Python code could be statically typed. Tracing JITs have already proven the value of call site specialization to a particular type.