PythonScriptBridge hardcoded Python path

Support
1

Hi Chris,

We are still using the PythonScriptBridge window in the client, because it makes life easier for many of our users. (Ultimately we’ll shift to a python server bridge in a terminal window, but not immediately).

From what I can see on github, it seems that the python executable path is hardcoded to /usr/bin/python2.6.

I’d prefer to use the system python2.7 (In particular, because you can use easy_install --user with 2.7 and not 2.6, and SIP doesn’t allow easy_install without --user to modify system directories). And in the future I may try to use a python from anaconda.
Is there an easy way to change the python executable path? Right now I’m planning to disable SIP and just rename it in /usr/bin.

Thanks,
Mark

2

Hi Mark,

MWClient’s Python bridge is hardcoded to use /usr/bin/python2.7 (and has been for several years). Why did you think it was invoking Python 2.6?

And in the future I may try to use a python from anaconda.

Adding support for alternative Python interpreters has been on my to-do list for quite a while, but so far there’s been no demand for it. I’d be happy to bump it up the list, if you think you’ll want it in the near future.

Cheers,
Chris

3

MWClient’s Python bridge is hardcoded to use /usr/bin/python2.7 (and has been for several years). Why did you think it was invoking Python 2.6?

Because I was looking at a very old github repository:

I noticed that I had gotten this wrong soon after sending, sorry for not updating you.

And in the future I may try to use a python from anaconda.

Adding support for alternative Python interpreters has been on my to-do list for quite a while, but so far there’s been no demand for it. I’d be happy to bump it up the list, if you think you’ll want it in the near future.

If I understand correctly, if we launch ourselves the python process running the bridge, we can use any interpreter. Is that right? If so, it’s probably not worth your time to change as we’ll eventually go to a server bridge running in a terminal.

The system python has numpy, but not scipy, so it’s not ideal for plotting as scipy is a real bear to install from source.

Mark

4

If I understand correctly, if we launch ourselves the python process running the bridge, we can use any interpreter. Is that right?

I think that was sort of true in the past, but it’s not any more.

It shouldn’t be too big of a job to add support for different interpreters. I’ll try to get it done in the relatively near future.

Chris

5

Thanks. Just out of curiosity, what is the issue that prevents using different python versions on the other side of the bridge?
I thought they communicated only via a pipe/socket?

Have a good day,
Mark

6

Hi Mark,

Just out of curiosity, what is the issue that prevents using different python versions on the other side of the bridge?

We discussed this offline, but I’ll answer here, too, for the benefit of the archive:

MWorks’ Python package includes a C++ extension module (/Library/Application Support/MWorks/Scripting/Python/mworks/_mworks.so) that is compiled against the OS X system Python (version 2.7). Prior to Python 3.2, Python’s developers made no guarantee of binary compatibility between major releases. This means that MWorks’ extension module would need to be compiled separately for every Python release we wanted to support. While that isn’t an insurmountable obstacle, our usage of Boost.Python complicates things a bit, and since no one has been requesting support for alternate Python versions, I haven’t pursued it.

Python 3.2 and later provide an opt-in method of ensuring that extension modules compiled for one version remain compatible with later ones. However, we won’t be able to take advantage of that unless we drop support for Python 2.7, which I don’t see happening soon. (Also, Boost.Python is again likely to complicate things.)

Cheers,
Chris