Missing "if __name__ == '__main__':" check in /usr/bin/ipython

[ncoghlan]

When executed, the top level ipython script always launches a new instance, even if the module is not being executed as __main__.

This is currently being worked around in the standard library (by special casing IPython), but the correct fix is for IPython to not launch a new instance when the module is being run as anything other than __main__.

[Carreau]

/usr/bin/Ipython is not ment to be imported it should only be used to run ipython from the command line, so it has no reason to check for main , or I'm missing something.

Also what are you refering to when you speak of standard lib? What are you trying to achieve ?

Envoyé de mon iPhone

Le 15 déc. 2013 à 12:47, ncoghlan notifications@github.com a écrit :

When executed, the top level ipython script always launches a new instance, even if the module is not being executed as main.

This is currently being worked around in the standard library (by special casing IPython), but the correct fix is for IPython to not launch a new instance when the module is being run as anything other than main.

—
Reply to this email directly or view it on GitHub.

[rkern]

All scripts should use the if __name__ == '__main__': boilerplate even if you never intend them to be imported. multiprocessing on Windows, due to the lack of a proper OS fork(), imports the main module as non-__main__ to set up the environment for the subprocesses. If the executable stuff is not guarded by the if __name__ == '__main__': boilerplate, then each subprocess will start executing the usual main process stuff and never let the multiprocessing subprocess stuff run. Here is the stdlib workaround Nick is referring to, I believe:

http://hg.python.org/cpython/file/51dddfead80a/Lib/multiprocessing/spawn.py#l230

[minrk]

I've run into that - I wish they had decided against supporting multiprocessing on Windows, given its many inconsistencies with other platforms.

[minrk]

fixed by #4700.

[minrk]

I'm a bit confused by the workaround since it seems to have been introduced in 2008, but this is the first we are hearing about a trivially fixed bug.

[ncoghlan]

I was confused as well (since there was no comment explaining why the
ipython specific check was there).

Python 3.4 now allows the use of Windows style multiprocessing on POSIX
systems, and it was while trying to fix some issues with that that I
encountered the workaround and tracked it back to the way the IPython
launch script worked. I suspect the original investigation just didn't
trace the problem back far enough to realise the root cause was in IPython
rather than multiprocessing.

Anyway, thanks for the quick fix! We'll keep the stdlib workaround for the
benefit of existing IPython releases.

[minrk]

The bug wouldn't affect any pip or easy_installed IPython, and I think distro packagers write their own entry points as well, though I may be wrong about that one.