Amqplib

Fix a packaging problem for Windows users, no changes
to the actual Python code.

A one-line change to transport.py to fix a problem older
FreeBSDs have with socket.getaddrinfo()

Otherwise just packaging changes to include more Trove
classifiers and docs/tests/etc in the source distribution file.

Big speedup for sending large messages. For example, sending
a single 100MB message on my machine goes from 90 seconds to
around 0.6 seconds.

Use setuptools if available, for enhanced functionality
for packagers.

Raise a ValueError if unserializable objects are present in
a Message's application_headers, instead of just quietly failing
and causing a connection to close.

Message objects can now be pickled/unpickled, previously unpickling
raised a RuntimeError: maximum recursion depth exceeded

PYTHON 3.x COMPATIBILITY

Code has been tweaked so that when 2to3 is run over the client
library and the unittests, the unittests will pass for Python
3.0, 3.1 and 3.2

There are some subtle behavioral changes to deal with how Python
3.x needs to encode/decode strings and they go/come over the
wire. Message bodies are encoded at transmission time, instead
of Message object creation time. Message application_header
strings are assumed to be encoded as UTF-8

Add support for queue_unbind, since RabbitMQ supports it as an extension
to the 0-8 protocol.

Add IPv6 support. The client uses socket.getaddrinfo(), so you can use
domain names with AAAA DNS records, or IPv6 literal addresses. If you
need to specify a port number along with a literal address, put the
address in square brackets (see RFC 2732), for example:
[::1]:5672

Some minor TCP changes, enabling keepalive, NODELAY (big speed
improvement there), shutting down sockets before closing to keep from
losing data (on Windows mainly?)

One minor change to watch out for is that low-level errors
such as a closed connection now appear as IOExceptions
instead of

TypeError: 'NoneType' object is not iterable

which never really explained anything.

Fix potential problem with library getting stuck in a loop
if the peer closed the socket. Also, break a few more references
when closing Connections and Channels, to help garbage collection.
Thanks for majek04... for pointing these out.

Add support for using Connection and Channel objects as context
managers for 'with' statements (available in Python >= 2.5), so you
can write code like:

with Connection() as conn:
with conn.channel() as ch:
do stuff with ch and conn

and have the Channel and Connection objects closed automatically
when the blocks exit.

Very large rearrangement of code, breaking the large client_0_8.py
module into submodules based on the various layers of the AMQP protocol.
The public API is unchanged however, so existing code that uses amqplib
should be unaffected.

----

nb_client_0_8.py and demos/nbdemo_receive.py were removed because of
the major changes to the main client to lay the groundwork for future
non-blocking behaviors (see http://hg.barryp.org/py-amqplib-devel/ )

----

More unittests added.

Get rid of Python 2.5-style conditional expressions, for
compatibility with Python 2.4 Thanks to Alexey Timanovsky
for pointing this out.

Send debugging output through the standard Python 'logging' module
instead of directly printing to the console.

Reworked the guts of the Connection and Channel classes
to untangle the mess that controlled how frames were
waited for and queued up. Should fix problems seen with
basic_deliver messages coming when the client is expecting
responses to other synchronous calls.

Added non-blocking client and demo, from
Dmitriy Samovskiy <dmitriy.samovskiycohesiveft.com>:
-----------------------
We put together an add-on for py-amqplib that implements AMQP client
with non-blocking sockets (see NonBlockingConnection class and
nbloop() function in nbclient_0_8.py). nbdemo_receive.py is a demo
script, and nbclient.zip includes both nbclient_0_8.py and
nbdemo_receive.py.

There are at least 2 scenarios where non-blocking sockets help, and
both are applicable to consumers:

1) when you want to be able to interrupt consumer's event loop
without waiting for a next incoming message;
2) when you want to consume messages from multiple brokers (or over
multiple connections) in a single event loop.

Did some profiling, found a big problem that caused a huge huge
number of unnecessary __getattr_ calls. Ran pylint and found some
bad coding style problems.