

In terms of the standard principal programming paradigms, Python is on the right-hand side in the “Shared state” column. Note two interesting things: first, Python’s box is represented by Java and OCaml; second, the box has two labels, “Sequential object-oriented programming” and “Stateful functional programming”. Python is technically a prototype-based language like ECMAScript, but it can be seen as either object-oriented or functional depending on whether we think of prototypes as classes or closures respectively.
Note that unlike “Imperative programming”, represented by Pascal and C, Python has closures. It does have closure quirk, also called lambda quirk, which ruins an otherwise-lexically-scoped language, but folks with lots of Python experience are used to working around closure quirk. Python functions are not procedures; they are sugar for objects with a .__call__()
method.
If this is your first time with the principal paradigms, please keep in mind the following quotes. First, from the associated book:
More is not better or worse than less, just different.
That is, Turing-completeness doesn’t have a canonical set of computational features. Second, from the chart PDF:
Two languages that implement the same paradigm can nevertheless have very different “flavors” for the programmer, because they make different choices on what programming techniques and styles to facilitate.
Some of those details are portable, particularly the behavior of code objects. Function declarations (
def
statements) bind code objects to names within a namespace; binding within aclass
namespace will create methods by calling the declared metaclass, which defaults to thetype()
builtin type object.Some other details are not portable. CPython stores code objects on the C heap and allocates generic closures; it supports either a
dict
from strings to locals, or user-declared slots naming a tuple of locals. PyPy automatically computes slots in all cases and supports thedict
as a special case. Threads generally share a single heap per interpreter, so the creation of threads doesn’t matter for declaring or instantiating objects; note that the community makes this work by pushing the convention that.__init__()
methods should not do computation and instead should merely initialize the locals, akin to similar conventions in C++. That said, Jython threads are Java threads, not OS threads like in CPython or PyPy, so normal assumptions about threading may not hold.You will have to let go of some of your practices around memory management. Python is memory-safe and garbage-collected by default; while sometimes you’ll want to remove names or map keys with
del
, it usually isn’t necessary. Similarly, while there are maybe a half-dozen ways to customize class creation and memory layout, it’s almost never actually necessary to use more than one of them at a time. Instead, stick to writing Pythonic code, and let runtimes like PyPy worry about performance. PyPy goes fast by simplifying what happens under the hood; if it exposed guaranteed internal structure then it would be slower.