# \[FEATURE\] Casting function for Perspective properties **URL:** \ **Category:** Ignition Early Access\ **Created:** [August 5, 2019, 7:50am UTC](https://forum.inductiveautomation.com/t/feature-casting-function-for-perspective-properties/27146 "2019-08-05T07:50:58Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![andrea.morando](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/andrea.morando/32/8039_2.png) [@andrea.morando](https://forum.inductiveautomation.com/u/andrea.morando)\ **Post date:** [August 5, 2019, 7:50am UTC](https://forum.inductiveautomation.com/t/feature-casting-function-for-perspective-properties/27146/1 "2019-08-05T07:50:59Z")
Dear all, I often have some troubles in managing the property datatypes in Perspective. In some cases, I need to convert them in python standard datatypes (list, dictionary, etc.), for example for using the “system.tag.configure()” function. Is there the possibility to have an Ignition function, able to cast the Perspective datatypes to standard datatypes? In my coding I have managed the following datatypes (with some difficulties!): - com.inductiveautomation.perspective.gateway.script.PropertyTreeScriptWrapper$MapWrapper - org.python.core.PyArray - many “com.inductiveautomation.ignition.common.script.adapters”-like types It would be great to be able to manage the “Object” graphical property as a dictionary and an “Array” graphical property as a list. What do you think about? Thank you so much, as always. Andrea ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 5, 2019, 4:22pm UTC](https://forum.inductiveautomation.com/t/feature-casting-function-for-perspective-properties/27146/2 "2019-08-05T16:22:46Z")
This is a feature I’m actively working on. I’m hoping to do two things: 1. Make things that should act list lists, dictionaries, etc, _act_ more like lists/dictionaries/etc. In general, that means supporting common Python methods like `keys()`, `pop()`, etc. In addition, “magic” methods like ` __iter__ ()`, so that you can do `for x in propertyTree` or `if x in propTree`. 2. Make sure that these objects can be passed directly to the `list()` and `dict()` functions that already exist. That would be the idiomatic Python way to cast them to new objects of those types. That _will_ break the ability to directly update them (currently, things like property trees at least attempt to be directly mutable) but allow you to work with them as native Python types. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 5, 2019, 5:29pm UTC](https://forum.inductiveautomation.com/t/feature-casting-function-for-perspective-properties/27146/3 "2019-08-05T17:29:55Z")
> [@paul-griffith](#): > > This is a feature I’m actively working on. Consider doing this entirely with the python wrappers. The resulting objects will retain their Java identity and function within Perspective but will be mutable and iterable as if they were native python objects. If you register the wrappers correctly in the Python subsystem, the wrapping will be entirely automatic anywhere python calls a java method to retrieve one of these objects. And anywhere you deliberately call java2py within perspective to expose one of these objects to a python interface. Please take a look at my experience with Vision's PyComponentWrapper: > [@Transaction groups triggered expression item updating when trigger is false](http://forum.inductiveautomation.com/t/transaction-groups-triggered-expression-item-updating-when-trigger-is-false/17196/14): > > Ok, so I’ve been down the rabbit hole and found Ignition’s (undocumented) PyComponentWrapper. I haven’t deciphered it enough to be sure, but it seems to be invoked only for particular situations, based on the string constants in the class file (like “getComponent” and “getComponents”). To play with this, I constructed a conversion adapter like so: public class PyComponentAdapter implements PyObjectAdapter { public PyComponentAdapter() {} @Override public boolean canAdapt(Object jObj) { … Perspective's java objects treated this way will simply _ **be** _ python objects, too. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 5, 2019, 5:36pm UTC](https://forum.inductiveautomation.com/t/feature-casting-function-for-perspective-properties/27146/4 "2019-08-05T17:36:08Z")
Currently Perspective is already using the adapter system you mentioned - I’m just piggybacking my work on existing (you’ll notice the class of something like `view.container.custom` is something like `PropTreeScriptWrapper`, not `PropertyTree`. It gets tricky when users expect these Python objects to behave in certain ways - internally, our systems development team requested a lot of dictionary-like methods on property trees, for instance, so they could do a safe `tree.get("key", default)` instead of `tree['key']` and catching a KeyError. We also can’t expose them directly, because that kind of backend internal access would allow you to pretty easily break Perspective, or possibly the gateway itself, in a way that Vision scripting didn’t easily expose to you. I’m making abstract classes for map/sequence-like ‘wrapper’ types to inherit from so that we can avoid having these problems with unexpected behavior in the future. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [August 5, 2019, 6:03pm UTC](https://forum.inductiveautomation.com/t/feature-casting-function-for-perspective-properties/27146/5 "2019-08-05T18:03:45Z")
> [@paul-griffith](#): > > you’ll notice the class of something like Heh, I've stayed out from under Perspective's hood so far... waiting for the churn to subside. /: > [@paul-griffith](#): > > We also can’t expose them directly, because that kind of backend internal access would allow you to pretty easily break Perspective, or possibly the gateway itself, in a way that Vision scripting didn’t easily expose to you. Ah, but you may be missing an opportunity here: when you provide a custom wrapper for a java type, you can also _ **leave methods out** _. You can let jython work directly with these objects, but only in the ways you explicitly permit. This would be true even when accessing that object through other under-the-hood APIs. (: Also, it's really no more risky than what we can already do with other gateway scripts. Especially with reflection. /: