You can clone with
HTTPS or Subversion.
When calling from __future__ import unicode_literals in the standard python console, the result is as follows:
from __future__ import unicode_literals
>>> len('é') # standard Python: strings are byte strings
>>> from __future__ import unicode_literals
>>> len('é') # strings are now unicode strings:
In IPython, it doesn't work:
In : from __future__ import unicode_literals
In : len('é')
It does not work either when the future import is placed inside the ipython_config.py file:
c.InteractiveShellApp.exec_lines = ['from __future__ import division, unicode_literals' ]
The problem remains:
In : len('é')
@takluyver, you've had the most do do with our unicode machinery as of late. Does anything quick come to mind on this one? I'm assigning it to 0.12 so we try to ship a release that's as solid as possible on the unicode front...
What version were you trying with? I've just tried with master, and it works. I think this is the same root cause as #777, which was closed yesterday (by PR #784). Essentially, __future__ imports only affected compiling and executing code, not parsing it, until that was merged. A nasty oversight, I know.
Closing for now because I think it's already fixed in master, but please reopen it if you can replicate it with a fresh pull.
ah, you are right, I was using version .11. It is fixed in master indeed. But perhaps it would be worth writing a little test to check this?
(I'll try to do that when I've figured out how to run the IPython test suite... :-/)
To run the test suite, use
you can pass it any nose flags
or test specific submodules
iptest -v IPython.core
TST: add future unicode_literals test (#786)