Migrating to Python 2.6.x

My materials are developed and run in Python 2.5.2

I want to move some code to 3.x, but that is not possible because many of the external packages I use don't exist yet. (For example, like numpy).

So, I'll take an intermediate step and move on to 2.6.2.

My question is, if an external module is running on 2.5.2 but does not explicitly indicate that it is running on 2.6.x, can I assume that everything will be fine? Or not?

+2


source to share


4 answers


They will most likely work fine. Some things can call DeprecationWarnings, like the sha module, but they can be safely ignored. This is my gut feeling, of course you can hit some particular thing causing problems. Anyway, a quick glance at them should tell pretty quickly if your code is needed or not:



+8


source


The main problem would be to use whatever C-coded extensions you may be using: depending on your system, but especially on Windows, such extensions compiled for version 2.5 will most likely not work at all (or at least not quiet and reliable) since 2.6. This is not particularly different from, for example, going 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 will work python setup.py install

(perhaps with sudo

or registered as an administrator, depending on your installation) - you may need to download and install the appropriate "developer" packages, again depending on which system you are using and what you are already installed (for example, on Mac OS X you need to install Xcode - or at least a subset of it, but the easiest is to install everything that in turn requires you to register for free with the Apple Developer Connection and download a large Xcode package).



I'm not sure how this approach currently works on Windows, i.e. is it possible to use free-as-in-beer compilers like mingw or Microsoft "express" edition VS, or put $$ on MS to get the right compiler. However, most third-party extension developers take the path of shipping pre-built Windows binaries, precisely because recompiling users (or at least once) was a problem on Windows, and 2.6 is already widely supported by third parties (because after all it's just a simple recompilation for them too ;-), so you might be in luck and find all the precompiled executables you already have available for the extensions you are using.

+3


source


You cannot let this happen. However, you should be able to easily check if it works or not.

Also, don't bother trying to upgrade to 3.x for another year or two. 2.6 has many of the 3.0 features already ported to it, so the transition won't be all that bad once you do.

+2


source


It might be worth reading What New in the 2.6 documentation. While version 2.6 is for backward compatibility, there are a few changes that might catch code, specific code that does something weird (ex: hasattr()

used to swallow all bugs, now it swallows everything except SystemExit

and KeyboardInterrupt

, not that, which most people would notice, but there might be strange code where it makes a difference).

In addition, this code indicates changes you can make in the future that will make it easier to migrate to 3.x when reading your packages (for example, the difference between str and bytes, although they are synonyms in 2.6).

+1


source







All Articles