Use strings for address and parameters

[emlyn]

It's great to have an OSC library that works well and supports both Python 2 and Python 3.

One issue I have with it though, is that it doesn't seem to support string types for the address or for OSC parameters, but uses byte arrays instead.

It can get a bit tedious (and error-prone) having to convert backwards and forwards between strings and bytes all over the place (or remembering to prefix a b in front of literals), so it would be great if it accepted and returned strings instead of (or as well as) bytes.

You would have to decide on an encoding, but I think it's fine to assume utf8 (or if you want to be more flexible you can always have an optional constructor parameter for the encoding).

[tshirtman]

Sorry i only saw your message yesterday.

Yes, i conveniently decided that encoding wouldn't be my issue when writing the library, so everything in the lib is bytes, makes things a lot easier for the lib, and the assumption is that you are free to use your encoding to encode/decode what you pass to/receive from it.

Now, i guess we could add an encoding parameter to servers and clients, and if it's set, the server assumes every string it gets is encoded using encoding, and decode it before passing it around, and the client assumes everything it gets is unicode, and encode it using the encoding parameter.

If it's not set, the current behavior would happen, for compatibility, with error messages explaining the situation in case of misuses.

I'll try to see if that idea works well with the codebase soonish. If anybody wants to have a try at it, feel free to do PRs.

[emlyn]

Thanks, I understand the desire to leave out string encoding as a separate concern, but I think in this case it adversely affects usability. This is the only issue that prevents me using oscpy in all cases at the moment - if I don't need Python 2 compatibility something like pyOSC is still easier to use.

[tshirtman]

How does the requirement to pass an encoding='utf8' to your server/client instances (at creation) to have this feature, feel? does that sound like too much of a burden?

osc = OSCThreadServer(encoding='utf8')
osc = OSCClient(address, port, encoding='utf8')

then one could use the same api but with unicode everywhere?

Another alternative would be to have string versions of all the methods (ubind, etc), but that would certainly feel less pythonic, and a lot more work to maintain.

[tshirtman]

I think this should address it :).

[emlyn]

That looks awesome, I'll try it out when I get some time. Thanks for fixing this :-)

[tshirtman]

It was suggested to me that it's probably a good idea to allow to pass an error handler for calls to decode, so i'll probably add that.

[tshirtman]

see PR #4