{
    "info": {
        "author": "Peter A. Donis",
        "author_email": "peterdonis@alum.mit.edu",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 3 - Alpha",
            "Environment :: Console",
            "Environment :: MacOS X",
            "Environment :: Win32 (MS Windows)",
            "Environment :: X11 Applications :: GTK",
            "Environment :: X11 Applications :: KDE",
            "Environment :: X11 Applications :: Qt",
            "Intended Audience :: Developers",
            "License :: OSI Approved :: GNU General Public License (GPL)",
            "Operating System :: MacOS :: MacOS X",
            "Operating System :: Microsoft :: Windows",
            "Operating System :: POSIX",
            "Operating System :: POSIX :: Linux",
            "Programming Language :: Python",
            "Topic :: Software Development :: Libraries :: Python Modules"
        ],
        "description": "The PLIB package contains a number of useful sub-packages and\nmodules, all within the ``plib`` package namespace in order to\nminimize clutter in the top-level namespace of your Python\ninstallation. Each sub-directory of the ``plib`` directory\ncontains a sub-package, except for the ``test`` directory, which\ncontains the PLIB test suite. The source distribution also\ncontains an ``examples`` directory, which has example programs\nusing PLIB, and a ``scripts`` directory, which has a few\npost-install scripts. (The ``SetupHelper`` directory in the\nsource distribution is not installed; it contains a helper\nmodule for PLIB's setup script. SetupHelper is available as\na separate package from PyPI under the name ``setuphelper``.)\n\nNOTE: This is the \"legacy\" version of PLIB, with support\nfor older versions of Python (those that require any of\nthe \"backported\" implementations of builtins and standard\nlibrary functionality that PLIB provides). This version\nwill not receive any future updates except for critical\nbug fixes, if any.\n\nThe PLIB Sub-Packages\n=====================\n\nThe individual sub-packages and modules contain docstrings\nwith more information about their usage; here they are\nbriefly listed and described.\n\nPLIB.CLASSES\n------------\n\nEach of the modules in this sub-package contains a single\nclass with the same name; the ``ModuleProxy`` class from\nthe ``PLIB.UTILS`` sub-package is used to make all the classes\nappear in the ``plib.classes`` namespace. See the sub-package\nand ``ModuleProxy`` docstrings for more information.\n\nThe classes in this sub-package are mostly a miscellaneous\ngroup, included for no other reason than that I have found\nthem useful. The only common theme shared by some of them is\nimplementation of common \"policy\" for I/O clients and servers,\non top of the basic mechanisms provided by the I/O channel\nclasses in ``plib.stdlib``.\n\nPLIB.EXTENSIONS\n---------------\n\nThis sub-package provides a namespace for functions (and\npossibly, in the future, other objects) exported from an\nextension module written using the Python/C API. The general\nphilosophy of PLIB is to do everything possible in pure\nPython, so the only functions that appear in this sub-package\nare those which by their very nature cannot be done in pure\nPython.\n\nPLIB.GUI\n--------\n\nThis is the largest sub-package, and contains a simple GUI\napplication framework with two main features:\n\n- It lets the same high-level code work with a number of\n  different underlying GUI toolkits. Currently supported:\n  Qt (versions 3 and 4), KDE (versions 3 and 4), wxWidgets,\n  and GTK. (The original reason for writing this sub-package\n  was that wxWidgets doesn't use Qt and I like the Qt/KDE\n  widgets better, but I wanted code that would run\n  cross-platform.)\n\n- It allows you to express the layout of your GUI in terms\n  of Python lists and dicts, enabling a much more declarative\n  and easy to read (and maintain) coding style.\n\nOther than selecting the toolkit (which may not be necessary:\nthe main module of the sub-package can 'auto-detect' which\ntoolkit to use--the ``plib-setup-gui`` post-install script\ndoes most of the work to enable this--so you only need to\noverride if you don't like the default), you should not have\nto worry about any toolkit internal details; the goal of this\nsub-package is to make them all look the same to your code.\n\nNote that the GTK toolkit support in this sub-package is\n\"experimental\" and may be removed if it proves to be more\ntrouble than it's worth. It's currently included because\nwxWidgets' behavior when using GTK as its underlying GUI\nframework has some quirks that I haven't been able to work\naround yet. However, the GTK implementation of a number of\nwidgets (particularly tables and list/tree views) is much\nless capable than the wxWidgets one, so the Python code for\nGTK ends up relying much more on ugly hacks.\n\nPLIB.INI\n--------\n\nThis sub-package implements an abstract 'INI file' API that\nuses ``ConfigParser`` on POSIX systems, and the Windows registry\non Windows systems. As with the ``PLIB.GUI`` sub-package, the\ngoal is to hide the internal details of the configuration\nstorage from your code, so all you have to do is define\nyour configuration structure, again using native Python data\ntypes (lists and dicts).\n\nPLIB.STDLIB\n-----------\n\nThis is a namespace for various functions and classes that\nextend or emulate the Python standard library. Some,\nlike the ``cached_property`` decorator, are implementations of\npatterns that have been known for some time, but which don't\nhave a \"canonical\" version in the stdlib yet; rather than\nhave PLIB depend on some other third-party package, I've\nsimply provided my own implementations here. Others, like\nthe ``abstractcontainer`` class and its subclasses, are\nre-implementations of standard Python data structures,\nwritten to enable PLIB to make as many things as possible\nlook like those data structures without having to subclass\nthe built-ins (which has some downsides for the use cases\nI've had thus far--see the docstrings for more information).\n\nThe ``plib.stdlib`` namespace also contains a convenience\nfunction. ``upgrade_builtins``; calling this function adds\nequivalents to the ``__builtin__`` module namespace for built-in\nfunctions that are not present in the running version of\nPython but are present in later versions. This is more\nconvenient than having to worry about importing such\nequivalents from ``plib.stdlib``; as a consequence, a number\nof functions are now removed from the ``plib.stdlib``\nnamespace and are instead provided by this function when the\nbuilt-in equivalents are not present. In this version of\n``plib``, you need to call this function somewhere in your\ncode (but only once); future versions may automagically\ninvoke it as long as you import anything from ``plib``. I\nshould also note that I have snuck in a few extra\n\"built-ins\" that are not in the Python standard library but\nIMHO should be. :-) See the docstrings for more details.\n\nThere are also five modules visible in this sub-package\nnamespace:\n\n- The ``coll`` module provides two slightly customized collection\n  classes, ``fifo`` and ``stack``, with a common API. This\n  module also includes the contents of the ``collections``\n  module from the standard library, so you don't have to import\n  both modules; in addition, for Python versions where some of\n  the classes are not yet present (``defaultdict`` and/or\n  ``namedtuple``), equivalents are provided. (The equivalent\n  implementation of ``namedtuple`` is taken from the ActiveState\n  recipe that led to the Python 2.6 implementation.)\n\n- The ``decotools`` module provides functions and factories for\n  working with decorators.\n\n- The ``func`` module provides an alternate implementation of\n  the ``functools`` module in the Python standard library for\n  Python versions prior to 2.5 (in 2.5 and later it simply\n  makes the functools module contents appear in its namespace,\n  so you can safely ``from plib.stdlib import func`` instead of\n  ``import functools`` and use the same functionality).\n\n- The ``options`` module provides an easier-to-use overlay for\n  the ``optparse`` module which allows you to express your option\n  configuration in the form of Python lists, tuples, and dicts,\n  and also adds some minimal argument checking functionality.\n  (NOTE: In Python 2.7 and later, this module now uses the\n  ``argparse`` module, since the ``optparse`` module is\n  deprecated. The ``argparse`` module provides additional\n  functionality for arguments, which can be accessed by making\n  the ``arglist`` parameter to the ``parse_options`` function\n  a sequence of 2-tuples to include keyword arguments, similar\n  to what is done for options.)\n\n- The ``timer`` module provides functions for timing code, with\n  an alternate API to the standard library's ``timeit`` module\n  that is easier to use when timing functions that you already\n  have as objects, instead of source code strings.\n\nPLIB.STDLIB.IO\n--------------\n\nThis sub-package contains classes that encapsulate various forms\nof client/server I/O channels. It is organized into sub-packages\nitself to make the namespace easier to use; the sub-packages fall\ninto three categories, and each sub-package in a given category\ncontains the same basic class names, so they're easier to remember.\nThe categories are:\n\n- **Device Types**: ``socket`` and ``serial``. Each device type has\n  a ``BaseClient`` and ``BaseServer`` class; the ``socket`` type\n  also has a ``BaseRequest`` class. These will usually not need to\n  be used directly; they are used by the I/O mode classes, and are\n  factored out so that each I/O mode sees the same API for a given\n  device type.\n\n- **I/O modes**: ``async`` and ``blocking`` (the latter does not just\n  mean synchronous: it includes a forking TCP socket server). Each\n  I/O mode has a client and server class for both device types, and\n  a request class for the ``socket`` device type: the class names are\n  ``SerialClient``, ``SerialServer``, ``SocketClient``, ``SocketServer``,\n  and ``BaseRequestHandler``. The ``async`` type also has \"persistent\"\n  classes, which support full-duplex asynchronous communication; these\n  are the ``PersistentSerial``, ``PersistentSocket``, and\n  ``PersistentRequestHandler`` classes. Mixin versions of these classes\n  (class names with ``Mixin`` at the end) are also provided, for use\n  if alternate data handling is desired (see next bullet), but it is\n  normally not necessary to use these \"by hand\"--see \"automatic mixins\"\n  below.\n\n- **Data Handling**: the I/O mode classes given above include basic\n  data handling, but it is *very* basic: the only way it can detect\n  that a \"message\" has been fully received is to detect a closed\n  channel. For some applications this is enough, but often more\n  sophisticated and robust data handling is needed. The ``data``\n  sub-package provides three mixin classes for this purpose,\n  ``ShutdownReadWrite``, ``TerminatorReadWrite`` and ``ReadWrite``.\n  The first of these detects the end of a received message by a\n  shutdown of the other end of the data channel, but keeps the channel\n  open to allow further writes (all the other classes default to\n  closing the channel when the other end closes). The other two\n  classes allow the detection of multiple \"messages\" in the data\n  stream, either by detecting a \"terminator\" string or by having\n  each message include its length at the beginning. These classes\n  also format outgoing messages the same way.\n\n*Automatic Mixins*: To derive your own client or server classes with\nalternate data handling \"by hand\", you would need to use the \"mixin\"\nversions of the appropriate I/O mode classes, and splice the data\nhandling class into the middle of the base class list; for example::\n\n    from plib.stdlib.io.async import SerialClientMixin, SerialBase\n    from plib.stdlib.io.data import TerminatorReadWrite\n    \n    class AsyncSerialClientWithTerminator(SerialClientMixin,\n        TerminatorReadWrite, SerialBase): pass\n\nThis is a bit clumsy, but necessary since the read/write handling has\nto be *before* the client/server class in the MRO, but *after* the\nbase device type, for the cooperative ``super`` calls that underlie\nthe functionality to work properly. However, since the pattern is the\nsame in each case, it can be automated, and this has been done in the\n``async`` and ``blocking`` sub-package namespaces, so that instead of\ndoing the above class construction \"by hand\", you can just append a\nsuffix to your desired class name, thus::\n\n    from plib.stdlib.io.async import SerialClientWithTerminator\n\nThe ``WithTerminator`` suffix (or, alternately, ``WithShutdown``\nor ``WithReadWrite``) will cause the equivalent of the above class\ndefinition to occur on the fly, so that the resulting class appears\nin the ``plib.stdlib.io.async`` namespace (of course the\n``plib.stdlib.io.blocking`` namespace has the same capability).\nOnce this has happened the first time, however, the class definition\nis stored in the appropriate namespace, so additional imports of the\nsame class name (in different modules of your application) will not\nre-do the \"on the fly\" construction; they will just retrieve the\nsame class object that was previously constructed.\n\nThe above machinery is also made available for use with your own custom\nread/write handling classes; the ``async`` and ``blocking`` sub-packages\neach export a ``get_readwrite_class`` function that does the same\non-the-fly class definition as above, but with your custom read/write\nclass instead of one of the built-in ones. All you have to do is pass\nthe function the name of your desired I/O class and your custom\nread/write class object::\n\n    from plib.stdlib.io import async\n    \n    class CustomReadWrite(object):\n        # class definition\n    \n    MyAsyncSerialClient = async.get_readwrite_class('SerialClient',\n        CustomReadWrite)\n\n*API Notes*: One of the goals of this sub-package is to provide a\ncommon, consistent API for all the different types of I/O, so that\nswitching one specific implementation of a certain functionality\nfor another can be done transparently to the rest of your application's\ncode. Thus, all of the usable classes follow the same basic pattern of\nmixing in the various pieces of functionality: from left to right\nin a class's MRO, one finds the type of endpoint (a client or\nserver mixin class, which may be specialized to the type of I/O),\nthe type of data formatting, if any (a mixin class from the\n``ReadWrite`` module), and the type of I/O, including device type\n(socket, serial port, etc.), mode (non-blocking/asynchronous vs.\nblocking), and basic data handling. Also, each endpoint type has\na common API independent of the specific type of I/O and mode; a\nclient can always use the ``client_communicate`` method to send\ndata to the server and receive a response; a server can always use\nthe ``serve_forever`` method to start itself; and all I/O objects\noverride the same methods to implement application-specific\nfunctionality: ``process_data``, to deal with data as it comes in,\nand ``query_done``, to determine when the I/O channel should be\nclosed. (To see examples of all this in action, look at the test\nsuite in ``test_stdlib_io.py`` and the library module for it,\n``stdlib_io_testlib.py``; the library module can use the same\nmixin classes to implement test functionality for *all* of the\ndifferent mixes of I/O classes in the test suite.)\n\nPLIB.UTILS\n----------\n\nThis sub-package contains some miscellaneous useful\nfunctions and modules, and also the ``ModuleProxy`` class\nreferred to above.\n\nPLIB.XML\n--------\n\nThis sub-package requires the ``lxml`` extension, which uses\nthe very fast ``libxml2`` library but provides a Pythonic API\nsimilar to ElementTree. The reason for using ``lxml`` instead\nof ElementTree itself is that ``lxml`` has two key additional\nfeatures:\n\n- Custom element classes: the ``classes`` module in this\n  sub-package builds on this feature by using metaclasses\n  to automate DTD generation and validation, but the\n  feature is also great for many XML applications.\n\n- Full and *fast* XPATH support: this was key in the XML\n  application that first prompted me to write this sub-package.\n  Yes, I know there are plenty of other Python XML packages\n  that do XPATH; the point is to have it *plus* the standard\n  ElementTree API *plus* the speed of ``libxml2``.\n\nInstallation\n============\n\nTo install PLIB, you can simply run::\n\n    $ python setup.py install\n\nat a shell prompt from the directory into which you\nunzipped the source tarball (the same directory that this\nREADME file is in). This will install PLIB and then\nrun each of the post-install scripts in the scripts\ndirectory.\n\nExample Programs\n================\n\nPLIB comes with example programs that illustrate key features\nof the package. After installation, these can be found in the\n``$PREFIX/share/plib/examples`` directory. If you have a\nPOSIX system (Linux or Mac OSX), the ``plib-setup-examples``\npost-install script will install symlinks to the example\nprograms in the ``$PREFIX/bin`` directory.",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "http://pypi.python.org/packages/source/p/plib2/plib2-0.7.3.tar.gz",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://pypi.python.org/pypi/plib2/0.7.3",
        "keywords": null,
        "license": "UNKNOWN",
        "maintainer": null,
        "maintainer_email": null,
        "name": "plib2",
        "package_url": "https://pypi.org/project/plib2/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/plib2/",
        "project_urls": {
            "Download": "http://pypi.python.org/packages/source/p/plib2/plib2-0.7.3.tar.gz",
            "Homepage": "http://pypi.python.org/pypi/plib2/0.7.3"
        },
        "release_url": "https://pypi.org/project/plib2/0.7.3/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "A namespace package for a number of useful sub-packages and modules.",
        "version": "0.7.3"
    },
    "last_serial": 749442,
    "releases": {
        "0.7.3": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "c08b7d5ab56c16dfda011795f4903172",
                    "sha256": "d1397b44fad2b5e512fa3cb84452aa2c40739098b171c0a4163afda722210859"
                },
                "downloads": -1,
                "filename": "plib2-0.7.3.tar.gz",
                "has_sig": false,
                "md5_digest": "c08b7d5ab56c16dfda011795f4903172",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 521734,
                "upload_time": "2012-08-15T05:04:53",
                "url": "https://files.pythonhosted.org/packages/55/45/df359f6afe733769082a4bf260ee5e7950ae9fcd106db6861c83bad8821c/plib2-0.7.3.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "c08b7d5ab56c16dfda011795f4903172",
                "sha256": "d1397b44fad2b5e512fa3cb84452aa2c40739098b171c0a4163afda722210859"
            },
            "downloads": -1,
            "filename": "plib2-0.7.3.tar.gz",
            "has_sig": false,
            "md5_digest": "c08b7d5ab56c16dfda011795f4903172",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 521734,
            "upload_time": "2012-08-15T05:04:53",
            "url": "https://files.pythonhosted.org/packages/55/45/df359f6afe733769082a4bf260ee5e7950ae9fcd106db6861c83bad8821c/plib2-0.7.3.tar.gz"
        }
    ]
}