Module Hierarchy

• ansi: This holds a series of classes and functions for helping to manipulate ANSI color codes.
• argparser: This provides the ArgumentParser class which parses command arguments automatically into a dictionary as well as a series of Parser classes which handle single arguments and TypeCheckers which handle validating user input values and converting them into other types (string -> int...).
• commandmanager: Lyntin comes with a series of commands for manipulating aliases, actions, highlights, and various other things.
• engine: This holds the enginewhich both contains most of the other objects that do work in Lyntin as well as encapsulates the event queue, event handling methods, and some of the other singleton managers such as the HelpManager and the CommandManager.
• event: Holds the eventstructures in Lyntin.
• exported: This is the APIfor lyntin internals and is guaranteed to change very rarely even though we might change Lyntin's internals.
• helpmanager: Lyntin has a comprehensive helpsystem that can be accessed in-game through the "#help" command.
• history: The HistoryManager keeps track of the last 1000 lines of user input history.
• hooks: The engine is augmented by a series of hookswhich allow modules to execute functions without having to change Lyntin's internals.
• lyntin: This module holds the Lyntin "global variables" and constants as well as the main function which starts Lyntin off.
• manager: Managers manage things.
• modules: The modules package holds all of the dynamically loaded Lyntin modules.
  • modutils: This module holds helper functions for building other Lyntin modules.
• net: This holds the SocketCommunicator class which handles socket connections with a mud and polling the connection for data.
• session: Holds the functionality involved in sessions.
• ui: This is the ui package.
  • ui: Holds the ui components in lyntin as well as the Message class.
• utils: This has a series of utility functions that aren't related to classes in the application, but are useful in a variety of places.

Class Hierarchy

• argparser.ArgumentParser: This is the actual ArgumentParser class.
• argparser.Parser: This is the base class for the parsers that argumentparser uses to actually populate the dictionary with each argument.
  • argparser.ExtraIndexParser: This class captures the parsing behaviour for an index collector.
  • argparser.ExtraNamedParser: This class captures the parsing behaviour for a named value collector.
• argparser.TypeChecker: Trivial base class for argument checkers
  • argparser.BooleanChecker: Accept only boolean values using the utils.convert_boolean function.
  • argparser.BooleanOrNoneChecker: Accept only boolean values or special "not specified" values.
  • argparser.ChoiceChecker: Allows for a value to come from a selection of different strings.
  • argparser.EvalChecker: Evaluate its input argument as python code and return the resulting object.
  • argparser.IntChecker: Accept only integer values and return integer objects.
  • argparser.ReChecker: Compiles the incoming argument as a regular expression.
  • argparser.StringChecker: Essentiallly the same as the trivial base class, but it's explicit that we just return the string we take in without any transformation.
  • argparser.TimeChecker: Accepts a date specification.
  • argparser.TimeSpanChecker: Accepts an amount of time and converts it to a number of seconds.
• engine.Engine: This is the engine class.
• event.Event: This is the basic Event class.
  • event.EchoEvent: Echo events get created when the connected server sends a Telnet Echo request--either to tell us that the server is handling echo (echo off) or that the server will not handle echo (echo on).
  • event.InputEvent: A user input event is created whenever the user types something into their ui and it creates a user event from it.
  • event.MudEvent: A mud event is when the connected mud sends data to us.
  • event.OutputEvent: Sometimes it's necessary to put data that's going to the ui into an event so that it is displayed in the correct order.
  • event.ShutdownEvent: This calls sys.exit(0) which will trigger the Python atexit stuff.
  • event.SpamEvent: Certain things can kick off a call to spam a hook.
  • event.StartupEvent: Starts up and initializes Lyntin.
• exceptions.Exception: Common base class for all exceptions.
  • hooks.DoneSpammingException
  • argparser.ParserException
  • hooks.StopSpammingException
• hooks.Hook: Represents a (possibly empty) sequence of user-defined functions.
• manager.Manager: Base manager class for managing things in Lyntin.
  • commandmanager.CommandManager: The CommandManager holds a series of _CommandData objects and methods to manipulate and use them.
  • helpmanager.HelpManager: The HelpManager exists on the engine scoping--there is only one per Lyntin instance.
  • history.HistoryManager: Manages user data history.
  • hooks.HookManager: Manages creating hooks on demand as well as retrieving hooks and such.
• net.SocketCommunicator: The SocketCommunicator handles all incoming and outgoing data from and to the mud, telnet control codes, and some data transformations.
• session.Session: A session is a nice container of all the stuff that encompasses a user session: aliases, actions, commands...
• ui.ui.BaseUI: Base ui class.
• ui.ui.Message: Encapsulates a message to be written to the user.
• commandmanager._CommandData: Holds data relating to a command.