Defense of Design¶
This document explains why SimPy is designed the way it is and how its design evolved over time.
Original Design of SimPy 1¶
SimPy 1 was heavily inspired by Simula 67 and Simscript. The basic entity of the framework was a process. A process described a temporal sequence of actions.
In SimPy 1, you implemented a process by sub-classing Process
. The instance
of such a subclass carried both, process and simulation internal information,
whereat the latter wasn’t of any use to the process itself. The sequence of
actions of the process was specified in a method of the subclass, called the
process execution method (or PEM in short). A PEM interacted with the
simulation by yielding one of several keywords defined in the simulation
package.
The simulation itself was executed via module level functions. The simulation state was stored in the global scope. This made it very easy to implement and execute a simulation (despite from heaving to inherit from Process and instantianting the processes before starting their PEMs). However, having all simulation state global makes it hard to parallelize multiple simulations.
SimPy 1 also followed the “batteries included” approach, providing shared resources, monitoring, plotting, GUIs and multiple types of simulations (“normal”, real-time, manual stepping, with tracing).
The following code fragment shows how a simple simulation could be implemented in SimPy 1:
from SimPy.Simulation import Process, hold, initialize, activate, simulate
class MyProcess(Process):
def pem(self, repeat):
for i in range(repeat):
yield hold, self, 1
initialize()
proc = MyProcess()
activate(proc, proc.pem(3))
simulate(until=10)
sim = Simulation()
proc = MyProcess(sim=sim)
sim.activate(proc, proc.pem(3))
sim.simulate(until=10)
Changes in SimPy 2¶
Simpy 2 mostly sticked with Simpy 1’s design, but added an object orient API
for the execution of simulations, allowing them to be executed in parallel.
Since processes and the simulation state were so closely coupled, you now
needed to pass the Simulation
instance into your process to “bind” them to
that instance. Additionally, you still had to activate the process. If you
forgot to pass the simulation instance, the process would use a global instance
thereby breaking your program. SimPy 2’s OO-API looked like this:
from SimPy.Simulation import Simulation, Process, hold
class MyProcess(Process):
def pem(self, repeat):
for i in range(repeat):
yield hold, self, 1
sim = Simulation()
proc = MyProcess(sim=sim)
sim.activate(proc, proc.pem(3))
sim.simulate(until=10)
Changes and Decisions in SimPy 3¶
The original goals for SimPy 3 were to simplify and PEP8-ify its API and to clean up and modularize its internals. We knew from the beginning that our goals would not be achievable without breaking backwards compatibility with SimPy 2. However, we didn’t expect the API changes to become as extensive as they ended up to be.
We also removed some of the included batteries, namely SimPy’s plotting and GUI capabilities, since dedicated libraries like matplotlib or PySide do a much better job here.
However, by far the most changes are—from the end user’s view—mostly
syntactical. Thus, porting from 2 to 3 usually just means replacing a line of
SimPy 2 code with its SimPy3 equivalent (e.g., replacing yield hold, self,
1
with yield env.timeout(1)
).
In short, the most notable changes in SimPy 3 are:
- No more sub-classing of
Process
required. PEMs can even be simple module level functions. - The simulation state is now stored in an
Environment
which can also be used by a PEM to interact with the simulation. - PEMs now yield event objects. This implicates interesting new features and allows an easy extension with new event types.
These changes are causing the above example to now look like this:
from simpy import Environment, simulate
def pem(env, repeat):
for i in range(repeat):
yield env.timeout(i)
env = Environment()
env.process(pem(env, 7))
simulate(env, until=10)
The following sections describe these changes in detail:
No More Sub-classing of Process
¶
In Simpy 3, every Python generator can be used as a PEM, no matter if it is
a module level function or a method of an object. This reduces the amount of
code required for simple processes. The Process
class still exists, but you
don’t need to instantiate it by yourself, though. More on that later.
Processes Live in an Environment¶
Process and simulation state are decoupled. An Environment
holds the
simulation state and serves as base API for processes to create new events.
This allows you to implement advanced use cases by extending the Process
or
Environment
class without affecting other components.
For the same reason, the simulate()
method now is a module level function
that takes an environment to simulate.
Stronger Focus on Events¶
In former versions, PEMs needed to yield one of SimPy’s built-in keywords (like
hold
) to interact with the simulation. These keywords had to be imported
separately and were bound to some internal functions that were tightly
integrated with the Simulation
and Process
making it very hard to
extend SimPy with new functionality.
In Simpy 3, PEMs just need to yield events. There are various built-in event
types, but you can also create custom ones by making a subclass of
a BaseEvent
. Most events are generated by factory methods of
Environment
. For example, Environment.timeout()
creates a Timeout
event that replaces the hold
keyword.
The Process
is now also an event. You can now yield another process and
wait for it to finish. For example, think of a car-wash simulation were
“washing” is a process that the car processes can wait for once they enter the
washing station.
Creating Events via the Environment or Resources¶
The Environment
and resources have methods to create new events, e.g.
Environment.timeout()
or Resource.request()
. Each of these methods maps
to a certain event type. It creates a new instance of it and returns it, e.g.:
def event(self):
return Event()
To simplify things, we wanted to use the event classes directly as methods:
class Environment(object)
event = Event
This was, unfortunately, not directly possible and we had to wrap the classes
to behave like bound methods. Therefore, we introduced a BoundClass
:
class BoundClass(object):
"""Allows classes to behave like methods. The ``__get__()`` descriptor
is basically identical to ``function.__get__()`` and binds the first
argument of the ``cls`` to the descriptor instance.
"""
def __init__(self, cls):
self.cls = cls
def __get__(self, obj, type=None):
if obj is None:
return self.cls
return types.MethodType(self.cls, obj)
class Environment(object):
event = BoundClass(Event)
These methods are called a lot, so we added the event classes as
types.MethodType
to the instance of Environment
(or the resources,
respectively):
class Environment(object):
def __init__(self):
self.event = types.MethodType(Event, self)
It turned out the the class attributes (the BoundClass
instances) were now
quite useless, so we removed them allthough it was actually the “right” way to
to add classes as methods to another class.