[Python-ideas] problems with import

[Andrew Barnert]

On Saturday, June 28, 2014 8:48 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

>Neal Becker writes:
>
>> I think the semantics we'd want is that the 2 trees are effectively
>> merged, with the local overriding in the event of a conflict
>
>Maybe.  XEmacs does such overriding, and my experience is that users
>expect DWIM behavior (the "best" version gets used).  Typically local
>trees get out of date and may not be compatible with newer versions of
>the main tree updated by the OS's PMS, etc.  It makes things hard to
>diagnose.

Isn't Python already flexible enough here? Whichever one comes first in sys.path wins. If you (as a distro packager, a sysadmin, a user, or even a program at runtime) want to customize that order, it's trivial to do so. If even that isn't good enough, you can replace almost any piece of the import machinery pretty easily—you could write a custom finder that finds all versions and picks the one with the newest timestamp, or whatever you think is better. So, what do people want here that Python doesn't do?

Meanwhile, what I personally prefer is to let local beat global, as long as I have an easy way to check when that may not be a good idea anymore. For example, I had PyObjC 2.5.0 installed for my system Python 2.7, back when Apple was using 2.4.something. At some point, Apple switched to 2.5.1, so after installing that system upgrade, my local copy was no longer needed, or wanted. Fortunately, I have a script that I wrote for just that occasion that told me about it so I could uninstall it. 

I definitely wouldn't want Python to automatically start ignoring my 2.5.0 because there's a 2.5.1. I'd love it if something (Python, Apple's installer, a script that came with either Python or OS X, whatever) would alert me to the problem so I didn't need my own script, but I'm not expecting that.

Also, what's right for my primary dev machine is not necessarily what's right for my company's testing systems or live deployed servers, or our customers' disparate systems; all I can really do there is require PyObjC 2.5.0 and let whoever's in charge of the machine figure out that they may be able to get that by uninstalling instead of upgrading. Anything that tries to DWIM its way out of that problem is going to get things mysteriously wrong as often as it helps.