Well this is not an issue anymore, as python 3.2 is deprecated, and with python 3.4 and over, u'' support is now back in. You should either upgrade your distribution, or install an up to date python (using nix or linuxbrew).

In our case, upgrading the distribution we use is not an easy task, because we use Debian Wheezy in production in more than 2000+ servers. It is going to take time. There is probably a lot of python-gitlab users in this case.

Adding "from future import unicode_literals" at the top of python-gitlab modules is better because it gives the possibility to use Python 3's Unicode syntax in older versions of Python like 2.7.

Using unicode_literals might change the behavior and break tools depending on python-gitlab. I'm not sure of the benefits of this change.

@gpocentek no it won't change the behaviour, and there's no reason it would break tools (besides code that only runs on python 2.6, which has now been officially deprecated anyway, so breaking it is good!).

Basically, what it does is that str is the new unicode and bytes the new str. It's only affecting your modules, and whatever you export will still be seen as old str and unicode classes in python2.7 anyway.

The benefit is that it's a first step towards making the code base better suited for python 3, even though thanks to the reintroduction of u'' in python 3.3 and newer, supporting both 2.7 and 3.x (with x>3) is smoother even without that.

And it's also avoiding a whole range of issues related to str -> unicode conversions and the other way around.

@Asher256 you'll have to anyway update to Jessie pretty soon, as wheezy is getting deprecated, and only minor updates will be kept going up to 2018. And updating 2000+ servers should not be an issue if you're using a sensible deployment tool like ansible, chef or puppet (and if you're not, then you should work on that first!).

+1
@gauvain: I agree with Guyzmo about unicode_literals. It is a step towards making the code compatible with Python 3 (as well as Python >= 2.7).

@guyzmo: even tough we use Puppet to configure/deploy our servers, we need to be careful with some of them, to avoid down times ;-) . This is why the update could take few weeks.

I've not received bug reports about such issues in ages, so I don't think this is really needed.