# Classes loading using script console cause isinstance to return False

**URL:** <https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737>\
**Category:** Ignition\
**Created:** [May 18, 2022, 4:52pm UTC](https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737 "2022-05-18T16:52:07Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jonathan](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@Jonathan](https://forum.inductiveautomation.com/u/Jonathan)\
**Post date:** [May 18, 2022, 4:52pm UTC](https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737/1 "2022-05-18T16:52:07Z")

</div>

We have upgraded from 8.1.10 to 8.1.17 and we are see a difference in the way the script console is loading files/classes.

Here is an example

![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/9/a9c4bc009a388830ce3b2fbe3c19ab15e4fa0786.png)

![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/b/dbb271f650c729093fdfa169e4391df336fcf9dd.png)

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/5/e55dc7d6a1d899fa145fc59711566632e4f8076e.png)

It appears that the testClass.TestClass is getting loaded twice with two different ids. Once when the console starts and then again when I access the property on TestClass2 which references TestClass.

Any help on this would be great. This does not seem to be a problem when running the code in a client only a problem in the script console.

---

<div class="post-metadata">

**Author:** ![Jonathan](https://avatars.discourse-cdn.com/v4/letter/j/aeb1de/32.png) [@Jonathan](https://forum.inductiveautomation.com/u/Jonathan)\
**Post date:** [August 4, 2022, 8:16pm UTC](https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737/2 "2022-08-04T20:16:16Z")

</div>

Any ideas on this? It would really be nice to use the console to do quick code tests rather than having to go over to the client. We are now on 8.1.18 and this problem still exists.

---

<div class="post-metadata">

**Author:** ![scottmwyant](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/scottmwyant/32/66369_2.png) [@scottmwyant](https://forum.inductiveautomation.com/u/scottmwyant)\
**Post date:** [November 14, 2023, 2:00am UTC](https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737/3 "2023-11-14T02:00:19Z")

</div>

Bump.

I have a module in my project script library built around Python's `unittest`. For the time being, I intend to run the tests manually, for a semi-automated approach to testing.

The way the modules are loaded cause `unittest.TestCase.assertIsInstance()` to return `False` unexpectedly. I even validated that the `assert` is doing what you would think... see [jython/jython/lib-python/2.7/unittest/case.py](https://github.com/jython/jython/blob/1f8b1946f41185cec2c069d02489e92ad2471b90/lib-python/2.7/unittest/case.py#L965).

I've provided what I believe to be the smallest reproduceable test. It's not much different from what OP provided 18mo ago.

```auto
# --- moduleA -----------------------------------------------------------------
def run():
	
	print isinstance(tmp.moduleB.getClassC(), tmp.moduleC.C)
	# False ?
	
	print(isinstance(tmp.moduleC.C(), tmp.moduleC.C))
	# True

```

```auto
# --- moduleB -----------------------------------------------------------------
def getClassC():
	return tmp.moduleC.C()

```

```auto
# --- moduleC -----------------------------------------------------------------
class C(object):
	def __init__ (self):
		self.c = "c"

```

This can be called from the script console by `moduleA.run()`.

---

<div class="post-metadata">

**Author:** ![VinceV](https://avatars.discourse-cdn.com/v4/letter/v/bb73d2/32.png) [@VinceV](https://forum.inductiveautomation.com/u/VinceV)\
**Post date:** [November 18, 2024, 11:11am UTC](https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737/4 "2024-11-18T11:11:00Z")

</div>

Bump again. I just spent the last three hours debugging various parts of my code to figure out what caused `isinstance` to fail, and yes, somehow the class is loaded twice with different IDs when used in the script console.

Rather annoying that this does not work as expected. Makes it very cumbersome to quickly test a piece of code in the script console.

 ![afbeelding](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/e/aed09b5ca6b589042c2e1f1e46910982104e1685.png)

 ![afbeelding](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/1/c14401d57032e1adc0b425dd4143a000a0f2244c.png)

---

<div class="post-metadata">

**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:** [November 18, 2024, 12:36pm UTC](https://forum.inductiveautomation.com/t/classes-loading-using-script-console-cause-isinstance-to-return-false/59737/5 "2024-11-18T12:36:09Z")

</div>

See this topic:

> [@\[IGN-6503\]Project Library Script Initialization Races](https://forum.inductiveautomation.com/t/ign-6503-project-library-script-initialization-races/98636/2):
>
> I should mention that the work-around shown above should NOT be placed in all of your project library scripts. It solves the multiple execution problem but at the risk of AB-BA deadlock across interdependent scripts. Some thoughts: Definitions of simple functions and simple assignments to top-level constants do not need this fix. While multiple executions will repeatedly replace top level objects, the replacements are identical to the first pass--no harm, no foul. Definitions of top-lev…

But also, the script console is wrapped internally to capture output, so runs its own script module initialization, separate from Vision.