1

Using the advice in the answers to this question, I created a new type (_NotInFile) and singleton instance (NotInFile) to represent a special condition in a series of IronPython scripts. I tested my implementation in Python and IronPython (from the command line) and saw the correct and expected behavior.

I then passed my code to a colleague who is using my scripts via the dynamic scripting capabilities of C# in a large Visual Studio project. Using the exact same script, he sees the expression itm.data_attr is NotInFile return false when inspection of the value in itm.data_attr unequivocally shows that it is of type _NotInFile and can only be the singleton instance I created.

To be clear, my colleague is not making use of the NotInFile object himself. Instead, he is calling one of my scripts which instantiates a collection of objects (some of which have properties which are assigned the NotInFile singleton) and then, without operating on the collection at all, calling another one of my scripts to process the collection. When I make the same calls (from a command-line test script) the is operator performs as expected, when he does the same thing it appears to fail.

The only thing I can think of is that C# may be instantiating a separate "copy" of IronPython for the calls to the ingestion and processing scripts, and that each copy instantiates it's own copy of the singleton at a different memory address so that singleton instantiated in the second script is not, in fact, the same object as the stored reference to the singleton instantiated in the first script.

Have I correctly identified the problem? If so, can the C # dynamic scripting system be instructed to run two separate scripts in the same instance of IronPython?

Community
  • 1
  • 1
Larry Lustig
  • 49,320
  • 14
  • 110
  • 160
  • Uhm. Shouldn't that be `itm.data_attr is _NotInFile`? I hope you didn't write up this whole ... essay ... over a forgotten underscore! – mcmonkey4eva Jun 26 '13 at 01:44
  • No, that's the type and I'm attempting to compare to the singleton object of that type (similar to None and NoneType - I should have used NotInFileType for the type to be consistent). In any event, the problem is the difference in behavior when the same code is run in two different ways. The code works fine when called directly from an IronPython test script. – Larry Lustig Jun 26 '13 at 01:49
  • The issue you propose might be the reason for your problems. You would have to provide more information on how your scripts are used because C# on its own won't do anything. You could also have a look at the ironpython versions used (`import sys; print(sys.version_info);`) because there were some issues in the past (I think more with equals operator than the is keyword but who knows). – Simon Opelt Jun 26 '13 at 07:34
  • I will try to get the C# calling code from the person who is calling the scripts. I'm pretty sure our IronPython versions are compatible since we've exchanged large amounts of code in this usage scenario before. – Larry Lustig Jun 26 '13 at 12:59

1 Answers1

0

In addition to posting this question here at StackOverflow, I sent a link to the question to my colleague. He was able to determine that he was instantiating two different instances of the IronPython runtime and thus the two singletons were, in fact, different objects.

He changed his code slightly to run both scripts within a single instance of the Python runtime and the code began exhibiting the same (correct) behavior as in my tests. Therefore the answer to both my questions is "Yes" (the problem was two runtimes, and C# can use the same runtime for invoking several different scripts).

I will update this answer with the exact steps necessary to fix the problem in C# once I learn them from my colleague.

Larry Lustig
  • 49,320
  • 14
  • 110
  • 160