If contactInfo is a dict in a list, why does it return just a flat list?

this started as a totally different question, but as i dug i found more stuff that makes no sense. i was trying to un :fork_and_knife: some spaghetti code, when i managed to get this FINALLY USEFUL mistaken output:

no joke, i wish i could get this kind out outpuyt everytime i want to print() data...

anyway. since i just wanted to extract the email portion of the dict, i started in like so:

userdata = system.user.getUser('', 'ian')
email, sms = ''
ci = userdata.contactInfo    # <--- this gives me a list of... what?  isn't it a dict?
print(ci)    # <--- confirmed.  not a dict: [email: ian@no.io, sms: 444]
             #    should this not be [{'Delete':'','type':'email', ...}]??
for item in ci:
    #  yeah... i stopped here

system.perspective.print(email)

it's a list! it's a dict! it's a dataset! what the :fork_and_knife:. i do not understand these data structures. it's like working with MongoDB... can someone unpack this for me? are these strings? why aren't they quoted? i know i'm a bit OCD with this stuff, so bear with my exasperation as i try to find some rhyme and reason here. and i'm betting it's either something stupidly simple that i've overlooked, or it's Chtulu's own magic itself.

The type() function might be your friend as you try to figure things out.

It's a List of ContactInfo objects, which are a Java object that has a toString() implementation on it.

This is mentioned in the docs here where the User object is described.

3 Likes

how the :fork_and_knife: did you know that!?

after reading very closely the docs, this is at odds with what i perceive the output from my loop to be.

from the manual:

user.getContactInfo() - Returns a sequence of ContactInfo objects. Each of these objects will have a contactType and a value property representing the contact information. Both properties are strings.

so userdata.contactInfo should be an object from which i should be able to reference a property to get a value:

email = [item.value for item in ci if item.contactType == 'email'][0]  # <---  !!!
#    don't forget the *index* because why would i return a just string??
print(email)  # <--- FINALLY!!  ian@no.io

so what i'm deducing is that print() is doing something i'm not used to behind the scenes. for example when i first wrote the code, i expected a string output and print() gave me this: [u'ian@no.io'] which threw me for bit. that's not SOP. and it's likely Java's fault...:smiley:

i think i just have to learn that every :goat: :ram: thing is crammed into a list. like individually wrapped Lifesavers in a bag: unecessary but that's how they come.


furthermore, how on :earth_americas: did email and phone not make the cut as part of user!?!? :confused: that's been part of standard user data structure for the last 20+ years. SMH.

Just like objects in Python can have a __str()__ method, objects in Java can have a toString() method that provide an alternative string representation. Introspection via str() is for fools, up your game and use type(), even if just in addition to str().

Slow down and read the docs.

They're types of contact information, which is its own extensible concept inside Ignition.

1 Like

i don't know Java at all. and i stopped writing C++ decades ago. but making that comparison makes sense to me now. in fact, it's more like __repr__ than anything. and i am trying to slow down to read the docs, but i am on a deadline here. two more weeks and things should downshift dramatically.

this is the first time in my career i've ever come across data structures i don't know the contents of. it's got me flat-footed from the jump. so now i AM actually going back to 'typing' everything... no pun intended. :stuck_out_tongue:

and still think abstracting contact information is just dumb... IMLTHO. :smiley:

I still use the introspect() function from my ancient inspect.py script module. You might find it helpful, too. If only as a shortcut to all of the possible java documentation that might apply.

2 Likes

Also, a given user could have one, zero, or more than one of every contact type. And modules are able to provide their own contact info types (like an SMS number, or a slack ID, or whatever).

You could argue the base user class "should" know about the most common contact info types, but then we're using the abstraction wrong in the other direction; why are certain types special but others not?

fair point. hadn't considered that. i still associate user with a person in this context forgetting that user could be a team or a bot.

@pturmel the link didn't go to a script, just an index of searches. what that what you wanted?

EDIT: nm. found it. thank you. :slight_smile: can you give a use example?

print shared.inspect.introspect(someObject)

Or assign the output string to a text area's .text property.

sweeeet. :100: thank you!