views:

189

answers:

4

My stuff is developed and running on Python 2.5.2

I want to move some code to 3.x, but that isn't feasible because so many of the external packages I use are not there yet. (Like numpy for instance).

So, I'll do the intermediate step and go to 2.6.2.

My question: If an external module runs on 2.5.2, but doesn't explicitly state that it works with 2.6.x, can I assume it'll be fine? Or not?

Thanks.

+8  A: 

Most likely they will work just fine. Some things might cause DeprecationWarnings, for example sha module, but they can be ignored safely. This is my gut feeling, of course you can hit some specific thing causing problems. Anyway, a quick look over these should tell pretty fast whether your code needs work or not:

af
Just unit tested 30,000 lines of our application under 2.6. Worked great. One small problem in Exception handling (the .message attribute is deprecated) caught me.
S.Lott
+2  A: 

You can't assume that. However, you should be able to easily test if it works or not.

Also, do not bother trying to move to 3.x for another year or two. 2.6 has many of 3.0's features back-ported to it already, so the transition won't be that bad, once you do make it.

Wahnfrieden
+1  A: 

It is probably worth reading the What's New section of the 2.6 documentation. While 2.6 is designed to be backwards compatible, there are a few changes that could catch code, particular code that is doing something odd (example: hasattr() used to swallow all errors, now it swallows all but SystemExit and KeyboardInterrupt; not something that most people would notice, but there may be odd code where it would make a difference).

Also, that code indicates changes you can make going forward that will make it easier to move to 3.x when your packages are read (such as distinguishing between str and bytes even though they are synonyms in 2.6).

Kathy Van Stone
+3  A: 

The main issue will come with any C-coded extensions you may be using: depending on your system, but especially on Windows, such extensions, compiled for 2.5, are likely to not work at all (or at least not quietly and reliably) with 2.6. That's not particularly different from, e.g., migrating from 2.4 to 2.5 in the past.

The simplest solution (IMHO) is to get the sources for any such extensions and reinstall them. On most platforms, and for most extensions, python setup.py install (possibly with a sudo or logged in as administrator, depending on your installation) will work -- you may need to download and install proper "developer" packages, again depending on what system exactly you're using and what you have already installed (for example, on Mac OS X you need to install XCode -- or at least the gcc subset thereof, but it's simplest to install it all -- which in turn requires you to sign up for free at Apple Developer Connection and download the large XCode package).

I'm not sure how hassle-free this approach is on Windows at this time -- i.e., whether you can use free-as-in-beer compilers such as mingw or Microsoft's "express" edition of VS, or have to shell out $$ to MS to get the right compiler. However, most developers of third party extensions do go out on their way to supply ready Windows binaries, exactly because having the users recompile is (or at least used to be) a hassle on Windows, and 2.6 is already widely supported by third-party extension maintainers (since after all it IS just about a simple recompile for them, too;-), so you may be in luck and find all the precompiled binaries you need already available for the extensions you use.

Alex Martelli