Improvements to the recent unicode changes

[pelson]

#135 enabled unicode support, but it was quite limited for py2 users:

>>> import cf_units; cf_units.Unit(u'm²')
Unit('m?')

This change handles unicode much more uniformly, and only converts back to str at __str__ and raising exceptions. As a general rule, I've gone for "unicode in unicode out, str in str out". That essentially means that type(unit.origin) will be the same as the original type that you constructed the Unit with (unless it was an integer, in which case you will get str).

>>> type(cf_units.Unit('m').origin)
<type 'str'>

>>> type(cf_units.Unit(u'm²').origin)
<type 'unicode'>

>>> type(cf_units.Unit(2).origin)
<type 'str'>

The error handling is now far superior also:

>>> type(cf_units.Unit(u'ø'))
...
ValueError: [UT_UNKNOWN] Failed to parse unit "ø"

>>> type(cf_units.Unit(u'('))
Traceback (most recent call last):
...
ValueError: [UT_SUCCESS] Failed to parse unit "("

>>> type(cf_units.Unit('('))
Traceback (most recent call last):
...
ValueError: [UT_SUCCESS] Failed to parse unit "("

One of the main changes here is the introduction of the dunder __unicode__ method - __str__ must always return a string but we can choose to implement __unicode__ which can then be encoded to a str afterwards.

I'll be honest and say that this definitely has not been a fun experience. It has taken many hours longer than I'd hoped, and I've ended up finding some ugly warts in py2's str implementation (I knew they were there, but I hadn't realised how bad they were until I'd seen the py3 light 🌞 ).

This whole thing will be avoided on the day we drop py2 support. A decision is definitely needed in that regard. Perhaps we should follow suit from SciTools/cartopy#1186.

[coveralls]

Coverage increased (+1.9%) to 90.255% when pulling 3767bdd on pelson:unicode_pt2 into 1e9af2a on SciTools:master.

[pelson]

@bjlittle

[bjlittle]

@pelson Yup, nice.

[bjlittle]

@pelson Thanks! 👍