Дизайн конечного автомата Python

Есть эта модель дизайна для использования декораторов для реализации состоятельных машин. Из описания на странице:

декораторы используются для указания того, какие методы являются обработчиками событий для класса.

Есть пример кода на странице, а также довольно долго, поэтому я не буду вставлять его здесь).

В апреле 2009 года выпуск журнала Python я написал статью о встраивании государственного DSL внутри Python, используя Pyparding и Imputil. Этот код позволит вам написать модуль FractyLight.Pystate:

# trafficLight.pystate

# define state machine
statemachine TrafficLight:
    Red -> Green
    Green -> Yellow
    Yellow -> Red

# define some class level constants
Red.carsCanGo = False
Yellow.carsCanGo = True
Green.carsCanGo = True

Red.delay = wait(20)
Yellow.delay = wait(3)
Green.delay = wait(15)

и компилятор DSL создаст весь необходимый трафик, красный, желтый и зеленый классы, а также правильные методы передачи состояния. Код может вызвать эти классы, используя что-то вроде этого:

import statemachine
import trafficLight

tl = trafficLight.Red()
for i in range(6):
    print tl, "GO" if tl.carsCanGo else "STOP"
    tl.delay()
    tl = tl.next_state()

(к сожалению, иммутил был сброшен в Python 3.)

Я думаю, что ответ S. Lott является гораздо лучшим способом реализации государственного машины, но если вы все еще хотите продолжить свой подход, используя (штат, событие) Как ключ для вашего диктография лучше. Изменение вашего кода:

class HandlerFsm(object):

  _fsm = {
    ("state_a","event"): "next_state",
    #...
  }

Это, вероятно, зависит от того, насколько сложна ваша государственная машина. Для простых состоятельных машин, дикт диктографии (из клавиш событий к клавишам для DFAS или ключей событий до списков / наборов / кортежей клавишных ключей для NFA), вероятно, будет самая простая вещь для записи и понимать.

Для более сложных государственных машин я слышал хорошие вещи о SMC , который может составить декларативные описания состояний машины к коду в широком спектре языков, включая Python.

Я бы не подумал достать машину конечного состояния для работы с XML. Обычный способ сделать это, я думаю, это использовать стек:

class TrackInfoHandler(object):
    def __init__(self):
        self._stack=[]

    ## ================================== Event callbacks

    def startElement(self, name, attrs):
        cls = self.elementClasses[name]
        self._stack.append(cls(**attrs))

    def characters(self, ch):
        self._stack[-1].addCharacters(ch)

    def endElement(self, name):
        e = self._stack.pop()
        e.close()
        if self._stack:
            self._stack[-1].addElement(e)

Для каждого типа элемента, вам просто нужен класс, который поддерживает методы addCharacters, addElement, и close.

EDIT: Чтобы пояснить, да, я имею в виду, что машины конечных состояний - это, как правило, неправильный ответ, что, как техника программирования общего назначения, они - мусор, и вам следует держаться подальше от них.

Есть несколько действительно хорошо понимаемых, четко определенных проблем, для которых FSM являются хорошим решением. lex , например, хороший материал.

Тем не менее, ФСМ обычно плохо справляются с изменениями. Предположим, когда-нибудь Вы захотите добавить немного состояния, возможно, флаг "мы уже видели элемент X?". В коде выше, Вы добавляете булевый атрибут к соответствующему классу элементов и все. В машине с конечным состоянием вы удваиваете количество состояний и переходов.

Проблемы, которые сначала требуют конечного состояния, очень часто эволюционируют, чтобы требовать ещё большего количества состояний, как, например, число , в этот момент либо ваша схема FSM является тостом, либо, что ещё хуже, вы превращаете её в некую обобщённую машину состояний, и в этот момент вы действительно вляпались в неприятности. Чем дальше вы идете, тем больше ваши правила начинают вести себя как код, но на медленно интерпретируемом языке, который вы придумали, и который больше никто не знает, для которого нет отладчика и инструментов.