FlyingDiver wrote:I guess it depends on how you "reference it". If you want to print or log it, then I would unicode() it.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
FlyingDiver wrote:Just for a test, try putting this at the start of the .py file:
- Code: Select all
#!/usr/bin/env python
# -*- coding: utf-8 -*-
And see if it all works without the unicode() calls.
u”{0}”.format(x)
Colorado4Wheeler wrote:That was the first thing I tried. I mean, it should be there anyway if I'm being proper about Py coding in pre 3.0 Python (guilty as charged) but it doesn't fix it. I've tried that in several plugins that users complain about the non-ascii issue on. I did just try it again just for giggles and forced a foreign character and no love.
DaveL17 wrote:I unicode() everything. In fact I go one step further andwherever possible.
- Code: Select all
u”{0}”.format(x)
Tempting the fates, those errors have been silent for me since I started doing that.
Sent from my iPhone using Tapatalk
Colorado4Wheeler wrote:That's what I just did across the entire plugin. I've always regarded the 'u' as not really needed but I'm changing my thinking on that now, I'm going to use it on any string that hits Indigo I think.
FlyingDiver wrote:I need to do better about that myself.
u"{0:*^80}".format(" Hello World ")
>>> ********************************** Hello World *********************************
DaveL17 wrote:I unicode() everything. In fact I go one step further andwherever possible.
- Code: Select all
u”{0}”.format(x)
Tempting the fates, those errors have been silent for me since I started doing that.
Users browsing this forum: No registered users and 8 guests