[KevinH]

Hi DiapDelaer,

The more I think about this the more I think you should not need to remove unicode_literals from the plugin. You are right, keeping your code as close to Python 3 as possible is a good idea. The bug has to either be in my launcher code or the kindleunpack code someplace since those are the only places pathof() are used.

I've looked, and the first thing the bk.addotherfile does is run utf8_str() on the 'new.epub' passed in so that can't be it.

The first thing the launcher does is use utf8_argv to get utf-8 encoded versions of all command line arguments such as the module name, the outdir, ebook_root etc so that can't be it either.

And I checked and the first thing kindleunpack.py does in unpackBook is run utf8_str() on the infile and outdir paths.

So I simply can not see how any unicode at all makes it past those utf8_str() calls and they should be the only interface points where full unicode can enter.

So please leave in the unicode literals import and I will try to track down where exactly the unicode path pieces are getting past the screens that should allow it to work nicely with full unicode with no warnings whatsoever.

Thanks,

Kevin

Originally Posted by KevinH

Hi DiapDealer,

Once I removed the from future unicode-literals from both mobi_stuff.py and KindleImport.py all warnings went away. When we built up the path to the epub using the literal 'mobi8' we were forcing the entire path to the new epub to be full unicode.

So unless KindleImport.py and mobi_stuff.py actually need the from future unicode_literals stuff, can we remove them?

When I build the python 3 interface, then I will move the python interfaces to be full unicode. Right now much of the launcher/wrapper code depends on the utf-8 strings much like KindleUnpack does.


Thanks,

Kevin