Python deprecated functions
Question:
I have a Django app written in Python 2.5 and I plan to upgrade it to be compatible with Python 2.6. It contains hundreds of .py files. Is there a simple way to find all deprecated functions in those files?
Answers:
I think Python 2.5 apps should work fine in 2.6 without updates. 2.6 might complain about some deprecated functionality but those are only removed in 3.0 and still work in 2.6.
Between point releases of Python (like between 2.5 and 2.6) anything that might break is a warning for at least one release. Most deprecation warnings are emitted by default but you have fine-grained control over the emitted warnings with the -W interpreter invocation option.
This is a relatively small issue between point releases as they are explicitly intended to be backward compatible. A bigger change is between Python 2.x and 3.0 for which some special-purpose tools including the -3 interpreter invocation option which shows the Python 3.0 related deprecation warnings.
I’m not sure what you mean by "deprecated functions" when upgrading from Python 2.5 to Python 2.6.
The release notes are very specific.
There aren’t any deprecated functions. A few whole modules are deprecated, and one attribute of the Exception class.
You have grep (or find) and you have Python which you can use to search 100’s of files of Python source.
When we made the change from 2.5 to 2.6 we had zero issues with deprecated functions.
Deprecated means "still works".
We had exactly one deprecated module, and it was reported during our unit testing via a warning message. We simply read the log for deprecation messages and replaced the module. (It was md5, by the way.) Eventually, we did a grep for all uses of md5 and replaced them.
The real deal is to migrate from 2.6 to 3.0. If you want to know all about it, there is a very good speech for that:
It includes:
- incompatibilities;
- work around;
- to-dos;
- automatic migration tools.
More and more I am persuaded that the right answer is "Just run your testsuite to find out." You have your testsuite covering your program reasonably, right? If not, this is a great opportunity to create one (you can persuade your pointy-haired boss that it is "migration" ;)).
I have a Django app written in Python 2.5 and I plan to upgrade it to be compatible with Python 2.6. It contains hundreds of .py files. Is there a simple way to find all deprecated functions in those files?
I think Python 2.5 apps should work fine in 2.6 without updates. 2.6 might complain about some deprecated functionality but those are only removed in 3.0 and still work in 2.6.
Between point releases of Python (like between 2.5 and 2.6) anything that might break is a warning for at least one release. Most deprecation warnings are emitted by default but you have fine-grained control over the emitted warnings with the -W interpreter invocation option.
This is a relatively small issue between point releases as they are explicitly intended to be backward compatible. A bigger change is between Python 2.x and 3.0 for which some special-purpose tools including the -3 interpreter invocation option which shows the Python 3.0 related deprecation warnings.
I’m not sure what you mean by "deprecated functions" when upgrading from Python 2.5 to Python 2.6.
The release notes are very specific.
There aren’t any deprecated functions. A few whole modules are deprecated, and one attribute of the Exception class.
You have grep (or find) and you have Python which you can use to search 100’s of files of Python source.
When we made the change from 2.5 to 2.6 we had zero issues with deprecated functions.
Deprecated means "still works".
We had exactly one deprecated module, and it was reported during our unit testing via a warning message. We simply read the log for deprecation messages and replaced the module. (It was md5, by the way.) Eventually, we did a grep for all uses of md5 and replaced them.
The real deal is to migrate from 2.6 to 3.0. If you want to know all about it, there is a very good speech for that:
It includes:
- incompatibilities;
- work around;
- to-dos;
- automatic migration tools.
More and more I am persuaded that the right answer is "Just run your testsuite to find out." You have your testsuite covering your program reasonably, right? If not, this is a great opportunity to create one (you can persuade your pointy-haired boss that it is "migration" ;)).