On Fri, Jun 26, 2020 at 3:38 PM Mark Shannon <m...@hotpy.org> wrote: > > What does "static and dynamic specifications" mean? Surely, there are > just specifications. >
There are specifications for both the runtime and the static aspects of the Python programming language. > Python does not have a static checking phase, The (C)Python *interpreter* doesn't. Other Python implementations (existing or hypothetical) may or may not have a static checking phase. But static tools need specifications beyond (ie. additionally to) runtime specifications, which are defined in PEP 483, 484, 585 and others. > Let us start from some anecdotal evidence: isinstance() is one of the > most called functions in large scale Python code-bases (by static call > count). In particular, when analyzing some multi-million line production > code base, it was discovered that isinstance() is the second most called > builtin function (after len()). Even taking into account builtin classes, > it is still in the top ten. Most of such calls are followed by specific > attribute access. > > Why use anecdotal evidence? I don't doubt the numbers, but it would be > better to use the standard library, or the top N most popular packages > from GitHub. > Maybe a scientific paper could be written on this subject. I'm guessing the "multi-million line production code base" in question is the Dropbox code base, and maybe Dropbox has an idiomatic way of writing Python with lots of "isinstance()"s. > In general, we believe that pattern matching has been proved to be a > useful and expressive tool in various modern languages. In particular, many > aspects of this PEP were inspired by how pattern matching works in Rust [3] > and Scala [4]. > > Both those languages are statically typed, which allows the compiler to > perform the much of the pattern matching at compile time. > > You should give examples from dynamic typed languages instead, e.g. > clojure. > Here's one example: https://github.com/clojure/core.match (in particular: https://github.com/clojure/core.match/wiki/Understanding-the-algorithm ). Alson some insights from https://softwareengineering.stackexchange.com/questions/237023/pattern-matching-in-clojure-vs-scala In this video <https://www.youtube.com/watch?v=dGVqrGmwOAw> I watched recently, Rich Hickey comments that he likes the destructuring part of languages like Scala, but not so much the pattern matching part, and he designed Clojure accordingly. That probably explains why the pattern matching is in a library and not as robust, although the kind of problems seen in the post you mentioned are clearly bugs. What Rich Hickey mentions as an alternative to pattern matching is multimethods <http://clojure.org/multimethods>. Most languages let you do polymorphic dispatch based on type. Some languages let you also do it based on a value. Using multimethods, Clojure lets you do it based on any arbitrary function. That's a pretty powerful concept. It comes down to the principle that programmers using a language should use the language's own best idioms. Trying to write Scala-like code in Clojure is going to have its difficulties, and vice versa. S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JWBAB4EC57NCTYREKPF63K6J347TCQXJ/ Code of Conduct: http://python.org/psf/codeofconduct/
