[EMAIL PROTECTED] a écrit : > When they have to ... > > One of the big things about Python is that its penetration slows it > down. There's more legacy code and interdependant systems around now > that Python is more successful and more mature. > > Here's a thought -- perhaps it would be worth having some good ways to > interact with Python from Python. Suppose you have some 2.4 code > someplace, interacting with your mysqldb or whatever, and you don't > want to rewrite it. So long as you have some kind of object broker, > you could (plausibly) leave your 2.4 apps running with the old > interpreter, but wrap them for Python 2.5 and use that in your new > development.
KISS please. > Ditto 3.0. > > Rather than having to re-write every interacting component, maybe it > could be straightforward to all Python2.4 from Python2.5 to execute > particular library calls. I'm not an expert, I don't know how you'd > build such a system, but I do know that re-writing stuff is a real > pain. Most of Python 2.4 source code is compatible with Python 2.5. Problems come with native compiled modules, you must have those for you 2.X Python version - some times just a compilation is enough. For Python 3.0, AFAIK its a big rewrite and developers know that it will be uncompatible in large parts with existing code. > Perhaps APIs for 2.5 and 3.0 could have a special version flag, and if > not present or not compatible, a 2.4 interpreter could be called > instead... Making Python interpreter bigger and more complex. Some code already has "hacks", trying to import a newer module and installing a fallback if its not available. If really your old Python 2.4 software cant run under Python 2.5, then you can have both Python 2.4 and 2.5 installed and running some code. Setup Pyro [1] on both, and go throught remote object invocation. And if you dont need new Python 2.5 stuff in your code evolution, just stay with 2.4, it works well. A+ Laurent. [1] http://pyro.sourceforge.net/ -- http://mail.python.org/mailman/listinfo/python-list
