Python 3.0 To Be Backwards Incompatible 438
Stony Stevenson writes "Organizations using Python will be affected in a major way by changes in store for the language over the course of the next twelve months, Linux.conf.au attendees were told this morning. The Python development community is working towards a new, backwards-incompatible version of the language, version 3.0, which is slated for release in early 2009. Anthony Baxter, the release manager for Python and a senior software engineer at Google Australia, said "We are going to break pretty much all the code. Pretty much every program will need changes." Baxter also added another tidbit for attendees, saying that Python accounts for around 15 percent of Google's code base."
It's a race (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
I really dont want to know ho perl will look in 20 years....
Re: (Score:3, Informative)
No. [programmersheaven.com]
Re:It's a race (Score:5, Informative)
> Will I be able to convert my Perl 5 programs to Perl 6?
> Yes. Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.
> In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.
Depending on who you talk to, this can be said to be backward compatible.
Re: (Score:3, Insightful)
At least the first form of "backward compatibility" mentioned (a translator for most older code) is also available (or a planned feature) for Python 3.0.
Much like python's approach (Score:3, Insightful)
Re: (Score:3, Informative)
Re:It's a race (Score:5, Informative)
See, the funny thing is that the changes going into Python 3 are fixes for much of what people have complained about in Python 2.x and prior.
Moreover, every step of the way they've built translators to move code from 2.x compatibility to 3.0 compatible -- and it'll catch when it can't translate the code and tell you as much. It seems pretty slick from everything I've seen. In many cases the fixes are ones you could easily do yourself in seconds with a good text editor. This will be a minor speed-bump for most users
For more info, check out the recent Doctor Dobb's Journal interview (audio) with David Goodger [ddj.com] -- it's about PyCon 2008, but it also covers Python 3 as well.
Re: (Score:3, Insightful)
The question is, who is going to have the hardest time interfacing to existing code?
In either case, things are changing that could present challenges to this. Perl is going to a new virtual machine. Python is changing things like string handling. Either one could he a show stopper when it comes to using existing code.
Neither Perl 5 nor Python 2 is going away. Interfacing with existing code would be a huge boost to either Perl 6 or Python 3, but of the two, I think Python 3 is more likely
Breaking backwards comp. in languages good (Score:5, Interesting)
You know, sometimes a little backward incompatibility can be good. You can shoot yourself in the foot more by not breaking things when something needs fixing. As an example I point to VB.Net.
Back in the days of VB 6 and prior, VB was an entry sort of language that was designed with novice programmers in mind, and strayed quite a bit from normal programming constructs. With the advent of the .Net platform looming, Microsoft wanted to move VB to .Net, but didn't want to break existing code out in businesses. So they opted instead for kludges and workarounds in the language, and that's the reason I can't wait to get done with VB .Net project I am currently writing. If you are an experienced programmer in other languages such as Java, C++, etc, VB .Net can drive you mad. Here are just a couple examples:
There are many other examples in VB like this, so I say this to the Python developers: If you have a good reason to break backwards compatibility with the language, then do it. Keep backwards compatibility whenever reasonably possible, but break it before accepting a kludge into your language. Your future coders will thank you, and will not run away screaming to the other, newer languages that will inevitably follow.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Re: (Score:3, Informative)
10.) Why do I have to tell VB what I'm "End"ing? "End For", "End Function", "End If" - wouldn't "End" be sufficient and then you could put a comment if you really cared what you were ending?
"End" is a keyword for termininating the application, and was like that since basic was invented. END IF and the likes were added when Basic was modified to use free-form code rather than sticking by line numbers that were in increments of 10.
You could do fancy things with NEXT in line number format, including violating the now common programming practices. After implementing blocked statements, you need to specify what you are ending in order to avoid a broken or mismatched FOR or IF block. As long as
Re: (Score:3, Insightful)
Re:Breaking backwards comp. in languages good (Score:5, Informative)
This was actually introduced prior to
Personally, I like the way Turbo Pascal made you declare both upper and lower bounds. 0-based arrays make sense in a systems programming language when it's just a thin veneer for a pointer, but VB, C# and Java shouldn't force it on you.
In the original VB, "And" and "Or" operators did NOT do short circuit evaluation.
Beyond that, they were bitwise operators, not logical. The fact that 1 is true, 2 is true, but 1 AND 2 is false is far more perverse than the lack of short-circuiting. This is also why the canonical true value in VB is -1 (1111111111111111 binary) rather than the usual 1. This was appropriate in Bill G's 8K Altair BASIC, but it should have been fixed in MS BASIC well before 1980.
VB.Net Beta 1 made "And" and "Or" normal logical operators and introduced new bitwise operators for the old functionality, but too many people complained and they switched it back for Beta 2.
There are many other examples in VB like this
I don't know about that. Those are pretty much the worst parts that
Re: (Score:3, Informative)
This is false. Arrays in all versions of VB were 0-based by default, as they were in all prior Microsoft dialects of BASIC, and as they were in the original BASIC interpreter. It always worked that way in BASIC: "DIM a%(10)" got you an array of 11 integers, with indices from 0 to 10. A QBasic extension to that which made its way into VB was the ability to define the lower bound explicitly, similar to Pascal. So you could write "DIM
It's not like this is the first time. (Score:3, Informative)
I didn't kill Python then, and it didn't stop us from using 1.5.2 for years to come for our old scripts and 2.x for our newer scripts.
Re: (Score:3, Interesting)
Re:It's not like this is the first time. (Score:5, Informative)
Many of them are backwards-incompatible changes that will remove nasty warts,
realign certain parts of python's object structure (str vs unicode, int vs long)
in ways that are MUCH cleaner, MUCH harder to make mistakes with, etc.
This is not some Larry Wall day dream revision...
they aren't rethinking python from the ground up,
it's an evolutionary revision which is keeping the python 2.x codebase,
but changing some things they've been wanting to do for a long long time.
The 1.x -> 2.x transition is apt... the code will look almost the same,
only cleaner
If that's not good enough for anyone, automated tools are being developed
to convert python 2.6 -> 3.0. Yes, that's right, Python 2.6. It'll
be the last version of 2.x released, and be carefully designed to be
both compatible w/ 2.x, and still able to warn you about gotcha's
that would appear if you ran the code under 3.0.
Not only that, but 3.0 isn't projected to be in mainstream use
for at least 2 more years.
There's absolutely no need for the sensationalist panic this slashdot headline
annouced itself with. Rethinking a complex system from the ground up is always
a bad idea... but GVR knows that, and that's not whats happening here.
It's more akin to the linux kernel moving from 2.4 -> 2.6
Incompatible, yes, but a much better architecture.
Re: (Score:3, Informative)
According to this index, anyway, Python [tiobe.com] has a respectable base and is slightly ahead of Perl. But, yeah, they could pull it off at this point.
Re:It's a race (Score:4, Funny)
>>>"python" > "perl"
True
Whereas if you ask perl:
perl -e 'print "python" > "perl"'
It remains silent, see?
Re: (Score:3, Interesting)
Re:It's a race (Score:5, Funny)
Re:Python to not be backwards compatible (Score:4, Informative)
If it isn't backwards compatible, it isn't Python, as far as I'm concerned. I'm sure not going to be re-writing a couple hundred megabytes of code. They can take their incompatible new snakelike thing and smoke it. Foregoing backwards compatibility is about as dim a move as I've ever seen anyone outside of Microsoft pull (MS dropping VB underneath Access comes to mind as a comparable clueless act, with exactly the same consequences — it isn't the same product and is useless to me.)
The reason for breaking compatibility is to maintain the Python philosophy of not having a lot of ways to accomplish the same thing. Without periodic pruning, eventually you'd just have Perl with indents.
From what I've read, you'll be able to choose the version/style you want, and the 2.x and 3.x series will live alongside each other (I don't know whether the 3.x interpreter will have a compatibility mode, or if you'll have to keep the 2.x version around as a separate program, though).
Re: (Score:3, Insightful)
which is the whole point of open source isn't it. 2.x will always be "free" and you can choose. a friend told me once that his firm did custom NT server (don't know or remember the specifics of the thing) install with their software (this was a long time back) and the firm pre-bought tons of NT licenses since they knew NT would be replaced and they wouldn't be able to get it anymore. that'll never happen with FOSS. and, that's the be
Re:Python to not be backwards compatible (Score:4, Insightful)
Re: (Score:3, Informative)
the problem is at some point they are going to drop support for it
Welcome to software development.
What products don't eventually become unsupported? Even a compiled language like C or C++ has libraries that eventually become unsupported, and maintaining them even if you had the source would become a difficult task.
Just rename it. (Score:5, Interesting)
Re:Just rename it. (Score:5, Funny)
There are already other [wikipedia.org] languages [wikipedia.org] doing this. If you think naming closely-related languages the same thing is a kludge, what do you think of naming mostly-unrelated languages the same thing?
Re:Just rename it. (Score:5, Funny)
Re:Just rename it. (Score:5, Informative)
The vast majority of the language and standard library will remain the same. This is just about tidying up some unfortunate warts that affect a lot of people, such as unifying the different string types. It remains Python in practically every way, and renaming it is simply unnecessary.
Re: (Score:2)
I hear the changes aren't supposed to be that drastic but then again, I have to wonder why the heads up if that was the case. Maybe as it gets closer, we will see that it is stuff so obscure that it won't bother 99% of everyone.
Re:Just rename it. (Score:5, Funny)
Python's named after the troupe Monty Python, not after the snake species. I don't think renaming it is a good idea, but suitable successors would be [Life of] Brian, [Fish Called] Wanda, Flying Circus, Holy Grail or perhaps start with sub-versions like Cleese, Chapman and Palin.
Alternatively, pick another troupe or favorite comedy show: Fry and Laurie, Mr. Bean, Fawlty Towers or Red Dwarf. Or my favorite, which brings back in the snake species AND British comedy into circular pun, Blackadder.
While talking about puns, snakes and coming full circle, I suggest Ouroboros.
Re: (Score:3, Funny)
Me: 'Yeah. They're ready to go, and they're all Fawlty now'.
I think we better stick with "Python". Or "Smeghead".
A cunning plan (Score:3, Insightful)
Re: (Score:3, Interesting)
Seriously, what really matters is:
#!/usr/bin/python2
or
#!/usr/bin/python3
And I'm betting someone will come up with
#!/usr/bin/python
that will automatically determine which python it is from the syntax.
Re: (Score:2, Informative)
Or does Ubuntu launch things based on file extensions?
Re:Damn right (Score:5, Informative)
2. Python 3.0 includes a 2to3 script to convert existing Python code to Python 3
3. The incompatibilities are mostly mechanical, by far the largest is the change of "print" from a statement to a function (which simplifies the implementation and makes converting existing programs to log to files or whatever much easier). I've yet to find any of my code that 2to3 doesn't handle just fine.
Re: (Score:3, Informative)
4. Unicode will become the standard throughout Python. This is probably the biggest change. Whereas before the String datatype was synonymous with a byte array (and used for both), it no longer will be. This entails some additional changes in your code to specify the encoding of a String, which will now be represented as Unicode. A new datatype, called "Bytes" (IIRC) can replace the former byte array use of Strings.
5. Many modules in the Standard Library which have been marked deprecated f
Re: (Score:3, Funny)
"THAT'S IT! I have had it with these muthafuckin' snakes on the covers of these muthafuckin' O'Reilly books!"
- Guido L. Jackson.
Re:Just rename it. (Score:4, Informative)
Another Shock Story (Score:5, Informative)
Re:Another Shock Story (Score:5, Interesting)
Yet everyone makes fun of me when I say that I am a C++ programmer.
Re: (Score:3, Funny)
This is already done in the distros I've seen.
Re:Another Shock Story (Score:5, Interesting)
Hopefully the Python team will learn from PHP's experience.
Re: (Score:3, Insightful)
Not a big issue for Python, methinks. Python is not generally used in hosted environments like PHP is. At least not in the same proportion. PHP's only real strength is its install base. You can get it on just about any host. To make a comparison outside of languages, PHP is like WIndows. The major selling point is its ubiquity. In which ca
How did that Cripple PHP (Score:5, Insightful)
PHP 4 had a php.ini setting to use the old mode (I think register globals or something similar) that helped in the migration. Also, include_once/require_once massive simplified using libraries. Before that we had to do our own equivalent of ifdef/ifndef in our PHP code to avoid overwriting a function if two included libraries called it.
The PHP 3 -> PHP 4 transition took a while as well. What's the rush, my new systems all include PHP4 AND PHP5. All my new code is PHP 5. My PHP4 stuff happens to be in legacy mode, but if I needed to bring it will us, you put it on a machine and see what works, what doesn't, and add support for 4 AND 5, like we all used to do on PHP 3/4.
Better to introduce some source incompatibility for improvements then not being able to move forward, just make sure that there is a transition strategy. Three years isn't really that long... though when I started in web stuff, 3 years was an eternity, but 8 years later, eh, just a few more years.
Re: (Score:3, Funny)
One can only guess when the next major overhaul will be. Who knows, it might even be PHP 6.
Re: (Score:2)
*shrug*
Re: (Score:3, Informative)
It's been a lot longer than two years. For example, see this thread [google.com] from eight years ago:
And from a reply:
Re:Another Shock Story (Score:5, Informative)
for i in range(1000):
# do something
will remain unaffected, but code that does something like:
a=range(1000)
a[37] = 2000
for i in a:
# do something
will be affected.
The conversion tool and 2.6 interpreter will warn you about those things, and they're easy to fix ( "a=list(range(1000))" ) if 2to3 doesn't do them automatically. Which I'm not sure about, because they're highly unusual--2to3 has converted all of my personal code just fine.
Workaround... (Score:5, Funny)
Just kidding Python fanbois :-)
Chill, it's Friday.
Re:Workaround... (Score:5, Informative)
Re: (Score:2)
print as function vs. keyword (Score:5, Informative)
print "This used to work"
You now have to do
print("This is how 3.0 rolls")
There will be no grandfathering, so everything needs to be refactored accordingly.
A small, but significant change.
Re:print as function vs. keyword (Score:5, Informative)
Actually, the migration tool 2to3 performs this change automatically, and the function call approach works in both 2.5 and 3.0, so the incompatibility is greatly exaggerated.
Re: (Score:3, Interesting)
If you're wondering why statements are stupid: they are not first class values you can pass, use and manipulate; they introduce a special, harder to learn and very quirky syntax; they cannot be used anywhere and thus subtract flexibility; and they are an extra form or feature that's actually unnecessary ("Programming languages should be
Re: (Score:3, Funny)
i.e. print "%03d %03d" % ( num1, num2 )
or, using a hash, print "%(foo)03d %(bar)03d" % { 'foo': num1, 'bar': num2, 'baz': num3 }
So, what exactly is Python missing here, oh wise and mighty smartass C programmer?
I don't see the problem (Score:5, Insightful)
Re: (Score:3, Informative)
Yes, there's the inevitable scary transition period with backwards incompatible upgrades, but after that's done, you'll be ready to reap the rewards.
I can't for example not thank Microsoft enough for making my life with Visual Basic code (yes, I have to deal with that occasionally in my job) far easier when they scrapped Visual Basic 6 and made something that must have been hundreds of incompatible cha
We have options. (Score:5, Insightful)
It is not like your favourite Linux distro is just going to drop the 2.x series overnight, or like Python 3 will fight 2.x on your system.
Whiners (Score:5, Insightful)
Tell, me exactly what would satisfy you? How about we just take your computer away.
I'm running for president! FREE PACIFIERS to all Slashdotters.
Re:Whiners (Score:4, Funny)
Re: (Score:2, Insightful)
Tell, me exactly what would satisfy you?
There's an obvious and simple solution that these stupid developers could implement if they weren't so lazy. As soon as they are done with the new backwards-incompatible code base they should just go back in time, preferably before I ever learned any code, and release it then. That way, all of the Python code I've written would have
Re:Whiners (Score:5, Funny)
It's almost like there's more than one person with an opinion on this!
meh (Score:5, Insightful)
It'll just be a case of slowly moving code from one version to the next.
This is a brave move, but you've only got to see the mess you can get into trying to force backward compatibility for too long (Vista, anyone) to know it's the right move.
Of course, this being python, I fully expect some brainbox to come up with an automated conversion routine (v2 to v3) that "WAS WRITTEN IN ONLY 15 LINES OF CODE". etc, etc.
in fact, such a utility already exists (Score:5, Informative)
And, as others have stated, there'll be the 2.6 branch, which will be backwards compatible.
Or, in other words, the story is stupid and misleading.
Sounds interesting (Score:2)
So long... (Score:2)
Would make the transition easier for everybody. My OS of choice (Gentoo) uses Python as the distribution method.
Version 3.0 of EVERYTHING should be rewritten (Score:2)
Python is doomed (Score:5, Funny)
Almost 2 years old? (Score:5, Informative)
- Python 3 (or Python 3000 as it was called) as a serious effort is more than a year old.
- There is already a working interpreter in its second alpha release.
- Final release is slated for August. (No infinite Perl 6 development.)
- Developers are working very hard to make the 2 to 3 transition as painless as possible.
- The Python team is committed to keeping the 2.x series going until 3.x has clearly been accepted.
You may now proceed to complain having been thus informed.For more info, check out (Score:5, Informative)
http://docs.python.org/dev/3.0/whatsnew/3.0.html [python.org]
Python Version Hell (Score:2)
I wish these scripting languages were really just APIs, and could all be compiled to binary code instead of depending on different versions of different interpreters. The script source is just too transient without needing to be when working under the hood.
Re: (Score:2)
So basically, you're looking for
Python3000 had some pretty grand visions. Optional static typing. Generic functions. Look what we got: meaningless type annotations on functions, not even on locals. "Abstract Base Classes"
Re: (Score:2)
But to really do waht I want, I'd need to actually compile those Python scripts in with the Perl executables, which I thought was too hard with autoloading and other dynamic runtime execution.
The Perl scripts can stay interpreted. They've never caused me any version trouble yet. Though I wish every CPAN downl
Following Microsoft's example? (Score:2)
I'd like to hear from slashdotters who used to blame Microsoft when Microsoft release software that broke backwards compatibility with existing versions. Is Python's development team following Microsoft's lead here?
Not news in any way (Score:5, Informative)
This has been known for donkey's years. Guido has been talking about this compatibility break since the 90s. The changes were laid out in detail in PEP 3000 [python.org], first published in 2006. They have already released two alphas. A conversion tool to automatically make some of the required changes (such as changing print statements to print() function calls) already exists [python.org].
philosophy (Score:3, Insightful)
IIRC, even dot-releases of python are not source-compatible. I assume that's why my install of Ubuntu has multiple versions of every library, e.g., /usr/lib/python2.4/smtplib.py and /usr/lib/python2.5/smtplib.py.
I think this is partly a matter of philosophy. The people in charge of a particular language tend to be computer language enthusiasts, and they like to tinker with them. They say things like, "The language has to be able to continue to evolve, or else it will die," or "We don't want to lock in things that, in retrospect, were really mistakes." But people actually using the language typically put a higher priority on not having their code break. Obviously we wouldn't all want to still be writing old-style fortran, with fixed columns, Hollerith codes, etc., but I also don't agree with the philosophy that "bit rot" is inevitable, and every piece of code you write is like a baby that you have to tend for the rest of your life. Personally, one of the things I really like about Perl is that it's got an excellent, mature implementation, and it's been mature for a long time. This is a lot less true for Ruby, for example, in my experience. It's true that Perl 6 is going to break backward compatibility with Perl 5, but the Perl 6 interpreter is going to automatically recognize Perl 5 code, and handle it correctly.
If this is news to you (Score:5, Insightful)
All for it. (Score:2)
Old news (Score:2)
Well I guess old news is better than no news at all...
Python takes a step backwards. (Score:3, Informative)
There's surprisingly little in Python 3.x that's really needed, and much that isn't. The approach to parameter typing (optional and unenforced) is silly. Having it and not enforcing it is just asking for trouble.
It probably would have been more productive to standardize on 2.6 and get a formal standard out the door, instead of using the CPython implementation as the standard. With a formal standard that couldn't be casually changed, the other implementations, all of which are faster than CPython, would have a firm target to implement. Python is twenty years old, and there still aren't multiple, compatible implementations.
Python could be a much higher performance language. Take a look at the Shed Skin implementation. One guy is trying to implement a hard-code compiler for Python that does type inference to determine types at compile time whenever possible. That yields a 10x-30x speedup. If you have rackmount servers running Python, that's a big win - one rack instead of ten.
Python has some optimization gotchas that really should be fixed. The big problem is "undetectable dynamism", or "if the only tool you have is a dictionary, everything looks like a hash". It's rare to store into a local variable of a function, or modify a method of a class from the outside of the class. Most classes don't have attributes added to them after creation. Python allows all these things, which can occasionally be useful. The trouble is that it's really tough to tell at compile time if the hard cases are going to be needed, and thus code has to be pessimized for the worst case.
This could be fixed with a few restrictions:
- Classes which can be dynamically modified from outside themselves should be subclasses of "dynamicobject" instead of "object". This makes everything dynamic but reduces performance. For most objects, the compiler can then find all the variables during
compilation, assign them fixed slots, and avoid having a dictionary in each object.
If an object indulges in self-modification or attribute creation, the compiler can see that at compile time and generate the slow code for the hard case. This is only needed for objects which are patched from outside themselves, something the compiler can't now detect and needs to know about.
- Variables cannot change major type during execution. If a variable is initialized with an integer or float value, it cannot thereafter be changed to an object type. Shed Skin imposes this restriction, which means it doesn't have to "box" numbers in objects and can hard-compile arithmetic.
This would make it possible to boost Python performance up to the Java level, and get it within striking distance of C/C++, yet not require declarations.Shocking! (Score:3, Funny)
Comment removed (Score:4, Insightful)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Have you ever used LISP? The editor reads the parenthesis, you read the indentation.
Indentation is a derived piece of structure, but should never have semantic meaning in a language except as a separator. Anytime you do so you ask for problems, both for editors, for code generators, and for users.
Re:So, will it FINALLY have block structures? (Score:5, Insightful)
Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?
Re: (Score:3, Insightful)
A=[[ 71, 211, 211, 131, 221, 131, 201, 221, 81, 214],
[ 131, 161, 141, 221, 51, 81, 171, 1, 241, 160],
[ 31, 201, 91, 41, 71, 111, 111, 191, 181,
Re: (Score:3, Insightful)
I find that your criticism falls at a surprisingly shallow level of thinking. You would think that someone famil
White semantics make plenty of sense, young buck (Score:2)
Whitespace Scoping and Block Scoping are two end of a dichotomy. Before you go wishin' it wasn't this way, well, i'm not going to belabor it but some of us like to actually be able to scan code without having to inspect every darn character to figure out where things start and end. It actually takes brain cycles to do that that could be spent on comprehension instead of syntactical flukery. It's a psychology thing not unlike the HID guideline (hid? in code? you
It does have block statements. (Score:3, Funny)
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Wrong. Any decent editor can automatically indent code for you in any langauge where the proper indentation can be unambiguously defined by applying a series of rules to some other set of constructs in the language. This works for any language that has an unambiguous block structure even in the absence of any significance given to different whitespace patterns, which is true of lots and lots of languages, but, notably, not Python.
Becaus
The Microsoft route (Score:4, Insightful)
Exactly! Now they can force people to buy expensive IDE's and servers to run the new version of Python, and strong-arm people into purchasing licenses to use the language for commercial purposes. It's just a money making ploy.
Oh, wait a minute. All the old versions are going to continue to be available -- even the source code. And it will remain free for commercial use. Hmmmm.
Sorry, but I fail to see how what they are doing is at all like Microsoft.
Re: (Score:3, Insightful)
Re:#1 way to prevent adoption of new language vers (Score:5, Informative)
First of all, the changes are mostly simplifications to the core language (e.g., how to catch exceptions is currently a bit of a mess if you want to catch more than one exception). So for example, range and xrange are now one, iterators become more prevalent, "old-style" classes are going away and so new-style ones will become the standard, a lot of the things that have been deprecated now are being removed, etc. It isn't really a "new language" in any sense. This is far superior to Java's "always backwards compatible" approach which has lead to a lot of cruft building up over the years.
Next, it needs to be understood that 2.6 will be backwards compatible and include a warnings mode to highlight things that won't work in Python 3.0 to ease in the transition. There should be no problem supporting both on one system.
Finally, they are providing a 2.5->3.0 translation tool that runs in 2.5 and does most of the mechanical translation between the two for you.