Unicode strings and Indigo Variables

Sorry if I am being thick...

1) I store info for some python code in a dict
2) I was storing that dict in an indigo variable using str(myDict)
3) I was retrieving the indigo variable into a python script, converting it from a string to dict using myDict = ast.literal_eval()
4) The contents of the dict appear to be Unicode now, causing problems in my script

Jay instructed me to convert the dict to json before storing in an indigo variable

Question: How do I reproduce this Unicode-related problem on my python editor outside of indigo?

I tried this

Code: Select all

 import ast
unicodeString = unicode("{'key1':'value1', 'key2':'value2'}")
uDict = ast.literal_eval(unicodeString)

But it yields this:

Code: Select all

 >>> uDict['key1']
'value1

Not this:

Code: Select all

u’value1’

<- which seemed to be happening when I pulled the string from Indigo before

Thoughts?




Sent from my iPhone using Tapatalk

Don't use ast.

Code: Select all

import json

r = json.dumps({'key1':'value1', 'key2':'value2'})
uDict = json.loads(r)
print uDict['key1']



this works for me:

Code: Select all

import json
theDict={'key1':'value1', 'key2':'value2'}
indigo.variable.updateValue("yourvarname",  json.dumps(theDict))

# if you like yo can look at it in a formatted way:
indigo.server.log( json.dumps(theDict, sort_keys=True, indent=4))

# and getting it back:
theDict = json.loads(indigo.variables["yourvarname"].value)


Karl

So if I do,,,

Code: Select all

import json
myDict = {'key1':'value1', 'key2':'value2'}
r = json.dumps(myDict)
uDict = json.loads(r)


... I get this:

Code: Select all

 >>> myDict
{'key2': 'value2', 'key1': 'value1'}
>>> type(myDict)
<type 'dict'>
>>> uDict
{u'key2': u'value2', u'key1': u'value1'}
>>> type(uDict)
<type 'dict'>
>>> r
'{"key2": "value2", "key1": "value1"}'
>>> type(r)
<type 'str'>


So I suppose I’m wondering how best to put a dict into an Indigo Variable so I can retrieve it with a python script and make it act like the dict when I made it, without all the u’’ business, which screws with my string operations and logging?

[jay (support)]

This line:

Code: Select all

unicodeString = unicode("{'key1':'value1', 'key2':'value2'}")

isn't doing what you think probably. It's converting this non unicode string:

Code: Select all

"{'key1':'value1', 'key2':'value2'}"

to a unicode string:

Code: Select all

u"{'key1':'value1', 'key2':'value2'}"

But none of the values inside are unicode - it's just one long non-unicode string. So when you use the ast module to reconstitute the string into an actual dict, it's reconstituting the dict values as non-unicode strings.

However, if you did this:

Code: Select all

uDict = ast.literal_eval("{'key1':u'value1', 'key2':u'value2'}")

Where you're explicitly making the strings unicode strings, then:

Code: Select all

>>> uDict["key1"]
u'value1'


Here's a brief cheat sheet of string vs unicode Python:

Code: Select all

>>> my_string = "I'm a standard string"
>>> my_string
"I'm a standard string"
>>> my_unicode_string = u"Here's a native unicode string"
>>> my_unicode_string
u"Here's a native unicode string"
>>> unicode(my_string)  # convert standard string to unicode string
u"I'm a standard string"


[jay (support)]

So I suppose I’m wondering how best to put a dict into an Indigo Variable so I can retrieve it with a python script and make it act like the dict when I made it, without all the u’’ business, which screws with my string operations and logging?

Code: Select all

myDict = {'key1': "value1", 'key2': "value2"}
indigo.variable.updateValue(123456789, value=json.dumps(myDict))
# At this point, the value of the Indigo variable with ID 123456789 is
#  {"key2": "value2", "key1": "value1"}
# Now, to get it back
myReconstitutedDict = json.loads(indigo.variables[123456789].value)


Now, perhaps this is where you get tripped up. This is what myReconstitutedDict looks like:

Code: Select all

>>> myReconstitutedDict
{u'key2': u'value2', u'key1': u'value1'}


because JSON string values are always returned as unicode strings. But this should make no difference for your script since in pretty much every other respect unicode strings can be used interchangeably with non-unicode strings.

If, however, something in your script isn't liking that, then you can convert the unicode string back to a non-unicode string:

Code: Select all

>>> str(myReconstitutedDict["key1"])
'value1'


assuming that there aren't any non ascii characters in the string.

If you would be more specific about the string operations and logging that isn't working then I'm sure we can help you figure that out.

I’m starting to get it, and THANK YOU, you nailed my lack of understanding on encoded dict entries.

Btw, my code was loaded with split() functions, running on strings taken from the dict. I think the split() functions may have been unhappy.

PS- This is all going towards a “switchboard” for the Dynamic Refreshing Image Plug-in, so different pages (for tablets in different rooms) can independently select their cameras to rotate displays.


Sent from my iPhone using Tapatalk

[jay (support)]

Btw, my code was loaded with split() functions, running on strings taken from the dict. I think the split() functions may have been unhappy.

split() should work with unicode strings the same way it works with non-unicode strings:

Code: Select all

>>> es = u"3.2.4.56"
>>> es.split(".")
[u'3', u'2', u'4', u'56']
>>>


If you were using split() to break up dicts that were encoded into strings, you were doing it wrong.

If you were using split() to break up dicts that were encoded into strings, you were doing it wrong.

(Laughing at work)
You could probably teach a CS elective of everything wrong I did writing this code!

Edit: FlyingDiver, I needed that. I am re-writing the whole thing using proper JSON!

What’s quicker? Reading from an Indigo Variable or from a local tex file (on an ssd)?


Sent from my iPhone using Tapatalk

[jay (support)]

What’s quicker? Reading from an Indigo Variable or from a local tex file (on an ssd)?

I doubt you'd notice any difference. The benefit to putting it into an Indigo variable is that you won't have to worry about the file getting moved, corrupt, etc.

If you do write it to a file, I highly recommend that you write it to the Plugin preferences directory so that the standard Indigo backup/restore/move process will maintain it:

Code: Select all

my_cache_file_path = "{}/Preferences/Plugins/your.plugin.id.cache".format(indigo.server.getInstallFolderPath())

Use your plugin ID as a namespace to avoid name collisions.