OSCPy 0.4.0

OSCPy has been getting some feedback and contributions over the last few months, which is pleasing, and I was able to add a few improvements.

Unicode support, servers and clients can declare an encoding for strings.

    It was previously required to only pass bytes strings as parameters,
    everything had to be encoded beforehand, and the callbacks would only
    get bytes strings. This design decision had been taken to simplify the
    design and make sure the handling of strings was coherent between python2
    and 3. This addition allows code on client or server side to declare
    encodings at any level required, and if so, only unicode strings
    (`unicode` in python2, `str` in python3) will be accepted accepted at
    input, and delivered at output. Implementing the "unicode sandwitch"

Fix timeout bug after 15mn without any activity.

    There was a nasty bug in the previous releases, that meant that if you
    only had one listener (most situations) didn't have *any* activity for
    over 15 minutes (not common for most usages, but definitly possible for
    some), then the listener would break, and you had to start it again.
    This blunter was fixed by always using `select`.

Allow answering to a specific port.

    The magical function to answer to a message always sent to the
    receiving port, which for a not connected protocol on udp, might not
    always make sense, so we now allow overriding it.

Allow callbacks to get the addresses they were called with. Add default_handler option for a server, to get all messages that didn't match any known address.

    These two allow using oscpy for some cases where it wasn't flexible
    before, like being a bridge, which means you don't always know which
    kind of messages you'll get, it also gives more power to callbacks
    bound to "smart" addresses (with parameters), so the callback know
    exactly why it was called.

Allow using default socket implicitly in OSCThreadServer.stop()

    Since we can bind to the default socket implicitly, it's now possible
    to also close the default socket implicitely.

Add statistics collections (messages/bytes sent/received) Add default routes to probe the server about existing routes and usage statistics.

    I decided it could be useful to have metrics of things happening to
    a live system, and so a few new default addresse/callbacks were defined to:
    - get the version of oscpy of the server
    - get the number of bytes/messages received by the server
    - introspect the exsting routes

    To do so, a statistics object was defined, which is updated by all the
    functions that send or receive messages.

Improve reliability of stopping server.

    In some situations, stopping the server doesn't work well, it seems to
    be related to the fact that the server could be receiving data when we
    close the socket, so we now make sure to empty it after that, so it can
    be released properly, there are still cases that aren't well treated
    apparently, because some tests are flacky because of that (It's rare though).

Add support for Midi messages

    A contribution that triggered important refactoring and improvements
    (although they weren't strictly necessary). We can now send and
    received the Midi type defined in the optional types of OSC. Since it's
    represented as a tuple, we decided to introduce a MidiTuple namedtuple
    for midi messages, it's necessary to use it to send a message, and
    receiving one will produce a MidiTuple.

Add support for True/False/Nil/Infinitum messages

    These extended types were easy to add, so they were added just after
    the midi messages, that did change the parsing a bit, because we match
    against values and not types at encoding. But it wasn't a big change.
    These are mapped to True/False/None/float('inf') respectively.

Add support for Symbol messages (treated as strings)

    This is another extended type that was easy to add, for now we only
    receive them, and dispatch them exactly like string messages, but
    a Symbol class could be created.

Test/Coverage of more python versions and OSs in CI

    Tests and coverage mesurements were introduced in github using
    travis-ci after the last release, python2 and multiples versions of
    python3 are tested, as well as pypy3.5 on Linux, multiple versions are
    also tested on Windows and OSX.

It's nice to see multiple projects using this library already, It might not seem like much, but it's always good to have feedback and news about what people do with a project.