etsdemo 'Run' button does not execute script in __main__ block

[kitchoi]

If one has a script that contains a block like this:

if __name__ == "__main__":
    ...

Trying to run this script from the etsdemo application by pressing the 'Run' button will not run that block, which is unexpected.

To reproduce, create a file like this:

if __name__ == "__main__":
    print("Hello")

Then run this:

from etsdemo.main import main
main(
    [
        {
            "version": 1,
            "name": "Some name",
            "root": ".",  # or a path to a directory that contains the above test file.
        },
    ]
)

That block is not run when one presses the 'Run' button.

But if one changes the "__main__" to "___main___" (three underscores), then it would run:

From the snapshot of an old version of the application, this ___main___ is not a typo: It looks deliberate.
https://github.com/enthought/traitsui/blob/96f45ff9c51ff55b5724cbed2361b933f468c183/enthought/traits/ui/extras/demo.py

Looks like the run_code method is serving two purposes:
(1) When the file is clicked, it loads the file to find this specially named variable 'demo'.
(2) When the Run button is clicked, it runs the file too.

For the first purpose, we don't want the block in if __name__ == "__main__" to run. For the second purpose, we do.

[corranwebster]

Note also the commented out code here:

traitsui/enthought/traits/ui/extras/demo.py

Lines 150 to 151 in 96f45ff

	locals['__name__'] = '__main__'
	#do_later(self.execute_test, df, locals)

Thoughts:

• using ___main___ is bad because then examples can't be run stand-alone from the command-line
• changing sys.modules['__main__'].__file__ a few lines later is highly dubious (and will potentially have weird impacts - e.g. this used by traits.etsconfig to guess the name of the current app and then after that the directories where to put configuration, etc...)
• perhaps the convention should be to have an optional main() function, and if __name__ == '__main__': just calls it?

[kitchoi]

using main is bad because then examples can't be run stand-alone from the command-line

Agreed. The invention of "___main___" looks like it was meant to make __name__ == "__main__" returns false, it would well be any value that is not "__main__"

changing sys.modules['main'].file a few lines later is highly dubious (and will potentially have weird impacts - e.g. this used by traits.etsconfig to guess the name of the current app and then after that the directories where to put configuration, etc...)

I have no idea what that side-effect is meant to do.

perhaps the convention should be to have an optional main() function, and if name == 'main': just calls it?

Hmmmm, I don't like these undocumented magical variables. The magical demo and popup named variables are undocumented conventions that change the runtime behaviour of the script. Ideally we want to be able to write these examples without knowing the existence of etsdemo.

Speaking of this demo variable, there is another catch here :D

If the demo variable is found in the local namespace, then I think it is intended that the if __name__ == "__main__": block would not be run, because the demo is expected to an instance of HasTraits whose default view can be shown in the "Demo" tab, so the main block is skipped. That works well for TraitsUI demo examples, where you have something like this:

demo = App()

if __name__ == "__main__":
    demo.configure_traits()

So instead of popping up a new dialog, the UI is shown in the Demo tab instead.

With TraitsUI example in mind, the Demo tab is the first tab. However some demo examples from Traits and Envisage may not have a UI, and the Output tab would have been a better default.

Perhaps we can solve all these by just removing the demo tab and the detection of the demo / popup variable? Then pressing the Run button will launch a new GUI, and that is consistent with the behaviour when one runs the script standalone from the command-line. What I don't want though, is that a GUI pops up when I click a node in the tree to browse an example.

[kitchoi]

On removing the demo tab,

consider this example in Traits: https://github.com/enthought/traits/blob/ce81921b0c55225c610b027440ff7a2fcdeb76e8/traits/examples/introduction/1_validation.py

There are no GUIs in this example. So the demo tab will be empty. The interesting information is in the 'Output' tab, which isn't the default tab and so it is hidden. The user would be left wondering why nothing seems to have happened after they click Run. (I believe the block of demo code there was not wrapped inside a if __name__ == '__main__' to counter exactly this issue.)

How about we rearrange the tab to make Output the default instead of Demo (i.e. effectively reverting #1075)? Then it is awkward to run TraitsUI examples, just like it is awkward to run Traits examples when the default tab is Demo.

How about we detect which of the tab the example is best shown in? More magic, more complexity. What if the magic got it wrong, then the user will have to flip back to the right one each time the Run button is run?

A lot of time when we write and review the examples, the context of the etsdemo application is not necessarily our primary concerns, we often want the examples to carry on working while run standalone from the command line.

All in all, I think removing the demo tab and making the execution of code in the etsdemo behaves more like how it is when the example is run from the command line will make the application easier to use and understand, result in less complexity in the code, and make it easier to write those examples (one does not need to worry about the etsdemo application).

[kitchoi]

I will open a separate issue for considering removing the demo tab, as this is a separate behaviour change to the issue described in the main comment... (edited: #1454)