Pythonised inputWire test

[wdednam]

Thought this one would be more straightforward, but it seems that the C++-wrapped findObject method does not expose more attributes to the pyminsky module than those in the item class, and, as a result, one can't access subattributes of specific item types directly from the object returned by findObject, e.g., name, valueId, etc. Thus, I have resorted to iterating minsky.model.items to expose the attribute required for the test (valueId).

---

This change is 

[wdednam]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @wdednam)

[highperformancecoder]

Thought this one would be more straightforward, but it seems that the C++-wrapped findObject method does not expose more attributes to the pyminsky module than those in the item class, and, as a result, one can't access subattributes of specific item types directly from the object returned by findObject, e.g., name, valueId, etc. Thus, I have resorted to iterating minsky.model.items to expose the attribute required for the test (valueId).

You're right - polymorphic objects are not currently supported on methods returning references. They should be of course, just like smart pointers support polymorphic behaviour of classes that inherit from PolyRESTProcessBase.

Also functions that return smart pointers should be supported, but don't work at all for some reason.

I'm going to add tickets to the classdesc project to do these, but it might be a while before getting to them.

[highperformancecoder]

Th Item::id() method is a more direct way of determining items match.

[highperformancecoder]

Also - in this case, the items list will have exactly two items - an IntOp and a Variable::integral. So we could just examine Item::classType()

[highperformancecoder]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @wdednam)