PyScripter, with the remote python engine option, runs python in a sub-process and communicates with it using sockets. The connection is local and does not present a security risk. As stated in an earlier post, in case the Firewall is an issue: Go to Control Panel\System and Security\Windows Defender Firewall\Customise Settings and make sure the "Notify me when Windows Defender blocks a new app" is checked. It is checked by default.
However there are users running under strictly controlled corporate environments in which even these "innocent" local TCP/IP connections are not allowed. So a few users could not load and connect to python. What can be done with the current version is:
- Enable the Internal Python Engine (Tools, Options, IDE options, Python, uncheck "Internal Interpreter hidden).
- Then go to the Python Versions dialog and try to load a python version.
The forthcoming version 3.5 offers another option: to communicate with the python engine using
Windows named pipes. There is no change in the user experience and it works faster than socket communication. The big advantage is that this bypasses firewall issues, since it does not use sockets. For PyScripter to be able to use named pipes the python module
pywin32 needs to be installed in your python version. Conda releases include the module. If you do a fresh install with versions from www.python.org you can add this module by issuing the command;
> pip install pywin32
at the command prompt or using the pip External tool in PyScripter. If the module is not available in your python version PyScripter will revert to using sockets as before. There is a new IDE option "Always use sockets" that will prevent PyScripter from using named pipes. This option is on by default. So if your firewall prevents for using the remote python engine, you should switch this option off. (Tools, Options, IDE Options, Python Interpreter, "Always use sockets").
No comments:
Post a Comment