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.
> I actually implemented dynamic loading of Python for OS X but since there
> are Python API changes between 2.3 and 2.5 you get a warning when trying
> to run on 2.3 if the binary was built using 2.5 (even though the library
> itself is successfullly loaded dynamically).
Yup, I saw that as well when playing around.
> 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.
Thanks,
Danek
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
