2009/2/17 Danek Duvall: > > björn wrote: > >> 2009/2/15 Danek Duvall: >> > >> > And further down that road would be to experiment with whether multiple >> > versions of Python can be loaded into memory at the same time. If that's >> > the case, then you could have different scripts running with different >> > versions in the same vim session. I don't know how useful that would be in >> > practice, though. >> >> This would be very useful for the Mac OS X port of Vim (MacVim) since >> 10.4 comes with Python 2.3 and 10.5 ships with Python 2.5. At the >> moment I link MacVim against 2.3 so that it works on both 10.4 and >> 10.5 but several users have requested 2.5. > > So that speaks for having multiple versions available, but not necessarily > for having them all co-resident.
Yes that is all I am after -- I can't see any particular use for having two or more co-resident. (?) >> By the way, how exactly do you propose to do this? Looking at your >> latest patch I assume you'd build one if_python module for each version >> and then decide which one to load when python is first used? > > That's the idea. I'm just not sure how that decision should be made. I > guess I'm looking for some guidance from Bram, though not being terribly > familiar with the vim development model, I don't know if I should be > looking elsewhere for that guidance. > > At any rate, if I were to hack something together right now, I'd probably > introduce a new variable that would let you set the order: > > set pythonversions=2.3,2.4,2.5 > > with tags of "oldest" and "newest" available as well. The first module > matching an element in the series that loaded properly would be the one > used, defaulting to either oldest or newest if the variable isn't set (or > if none of them match?). The modules would need to be named consistently > -- if_python<ver>.so -- and in a collatable order, though I suppose I could > always try to query the module for the definitive version if the collation > proves too difficult. > > But there might be some pitfalls behind that. Suggestions and guidance are > welcomed. I think this is overkill. Why not just see which modules are installed and try loading from newest to oldest? Well, maybe it isn't that simple since loading will probably work as long as the module is present even if the matching python version is not installed. But it provides pretty much the same functionality as the option you suggested (the user simply has to make sure that only the right module is installed) and it means less code. I'm pretty new to Vim development myself, but it seems the less new options you introduce the greater the chance that your patch will be accepted. Anyway, as far as OS X is concerned the best way would be if the most recent version of python installed was automatically used (judging from the requests I've had from users) without the need of user involvement. Would this be possible? (Assuming the user has the matching if_python modules installed...in the case of OS X these would be distributed with the Vim binary inside the so-called application bundle.) Björn --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
