I did a quick research into documentation and did not find any evidence that suggests argparse is supported before 2.6. We have development network as well as servers that use Python 2.5.1 to do a lot of things. I had an idea to upgrade it, but didn't realise that there is a change request process that needs to be gone through. I am wondering if I can have an alternative method to use something similar to argparse.
I know optparse is the other option, but it is also deprecated in 2.7.x versions. Does anyone know anything else?
argparse is included with Python from version 2.7 onwards.
You can install it from PyPI for earlier versions of Python, Python 2.3 and up is supported.
Based on discussions that I've seen on the Python bug issue site, optparse is not really deprecated. Don't expect further development, but it isn't going to disappear any time soon.
All of argparse is contained in one file, argparse.py. So you could grab that from almost anywhere, and put it on your load path. A possible exception is a recent Python3 version that has a gratuitous (IMO) 'nested-with' statement.
It's possible that there are other incompatibilities with Python 2.5, but it wouldn't be hard to test a 2.7 argparse.py in the 2.5 environment.
There is also a unittesting Lib/test/test_argparse.py file. Though that is more likely to be incompatible, since it is using some newer unittest functionality.
Related
I want to develop and test my project on the up-to-date version of Python 2.7 (say 2.7.18), but I want my project to be still fully usable on earlier versions of 2.7 (say 2.7.7). Setting up many variants of 2.7 locally or/and on CI for testing can be redundant.
So there are the following questions about compatibility of 2.7.X.
Can there be any changes in syntax which make code not working?
Can there be any changes in available standard imports, for example, can some imports from __future__ be unavailable in earlier versions?
Since I have to distribute compiled Python files (.pyc, compiled via py_compile module), I'm also wondering if there can be any changes in Python bytecode which block code execution in earlier versions.
I guess if all the answers are "no", I can develop and test my project only on a single 2.7 version without worries.
I've tried to search it but there is no success. Please share your experience and/or links.
UPD 1: I should have clearly said from the beginning that it's not my desire to use 2.7, it's a requirement from the environment.
At least Python 2.7.9 introduced massive changes to the 'ssl' module, so trying to use code using SSL for 2.7.18 on Python older than 2.7.9 will fail. So a clear "yes" to number 2.
In general compatbility for most projects works the other way round, use the oldest version you need to support and work upwards from old to new, not downwards from newer to older. I do not know of any software project that makes the guarantees in the other direction.
Note that Python 2.7 dropped out of support with 2.7.18, so unless you use a compatible version like PyPy (https://www.pypy.org/) your freshly developed project will run on outdated Python versions from the start.
If you want to provide a shrink wrapped product, maybe have a look at the usual solution for this like pyinstaller (https://www.pyinstaller.org/) or freeze (https://wiki.python.org/moin/Freeze)
The #3 may work, if you study the list of bytecode opcodes which do not change that much over time (https://github.com/python/cpython/commits/2.7/Include/opcode.h) but no idea if the on-disk format changed.
We have got a legacy application that runs on Python 2.2.1. Now we need to upgrade to the latest version of Python (3.4).
I would like to know a few details on the upgrade:
Would that be a direct upgrade for all of the associated files? I mean what libraries that have been used in the older code have to be changed to make it work in latest version?
How do we upgrade the .py files from the older to the newer version?
Everywhere it talks about upgrading 2.6 to 3 and nowhere does it cover 2.2.1 to 3. Is there any direct upgrade possible?
To expand on my comments, the PyPorting docs suggest a seven-step process that I think would be useful here too:
Only worry about supporting Python 2.7 - it will be easier for you to upgrade to 3 if you first make sure your code runs in the latest 2.x branch. If you're lucky, this won't require many changes!
Make sure you have good test coverage - crucial for any major change. If you can't be sure it's working now, how will you be sure it's working after the upgrade?
Learn the differences between Python 2 & 3 - per cdarke's comment, you will probably have to do some manual intervention, so will need to know what's changed. In your case, this may also involve learning the differences between 2.x versions. You can use What's new in Python x.x? to help.
Use Modernize or Futurize to update your code - automated tools to make your code 3.x-ready (the documentation notes that you can use 2to3 if you don't want to retain 2.x compatibility).
Use Pylint to help make sure you don’t regress on your Python 3 support - pylint will give you lots of helpful warnings to help improve the code generally.
Use caniusepython3 to find out which of your dependencies are blocking your use of Python 3 - you ask about updates to libraries; this tool can tell you what's 3.x compatible. You may need to find compatible replacements for some dependencies; see PyPI.
Use continuous integration to make sure you stay compatible with Python 2 & 3 - whatever versions you want to support, good CI can ensure that you stay compatible with all of them as you modify the code.
I would recommend that you take a look at something like: 2to3
The idea is that you can just run the program on your old file, and convert it to 3.4 compatible code. Best of luck!
I have a small application that runs on fairly recent Linux distributions with Python 2.7+ but also on CentOS and Scientific Linux boxes that have not yet made the switch to Python 2.7. optparse is deprecated with Python 2.7 and frankly I don't want to support optparse anyway, which is why I developed the application with argparse in mind. However, argparse does not exist on these older distributions. Moreover, the sysadmins are rather suspicious of installing a backport of argparse.
Now, that should I do? Stick with optparse? Write yet-another-wrapper around both libraries? Convince sysadmins and users (who in most cases are just able to start the application) to install an argparse backport?
I would stick with optparse as long as it provides the functionality you currently need (and expect to need in future).
optparse works perfectly fine, it just won't be developed further. It's still available in Python 3, so even if one day you decide to move to Python 3, it will continue to work.
Provide a copy of argparse.py with your program, since there is no need to install the module. It is sufficient to get argparse.py from pypi.python.org/pypi/argparse and place it in some location included in sys.path.
Can I use Python 2.7 modules from Python 2.6? Or do something to achieve the same effect?
I'm limited to use Python 2.6, but an issue exists in the subprocess module provided by Python 2.6. This is fixed in Python 2.7. I'm curious if I rig this up using pip (or equivalent) to sidestep the bug temporarily until upgrading one day. How would I go about doing this?
Yes, usually. The difference between 2.6 and 2.7 isn't very big, as 2.7 is supposed to be a bridge between 2.6 and 3.0. As a result, most Python modules for 2.7 will work in both of these versions (usually better in 2.6 than 3.0).
Of course, the only surefire way to know the answer is to try!
EDIT: To be clear, I do not recommend that you do this at all, if you have a choice.
Hacking around a Python installation just because of a Python bug in one module is a bad idea.
If you really want to stay on Python 2.6, but also want to fix this bug, I might suggest compiling Python 2.6 from source, but also applying the relevant bug fix code to the subprocess module from 2.7.
You will end up with a custom build of Python 2.6. Of course, if you're stuck on the standard 2.6 because you are unable to install any different version, then this won't help.
Etienne Perot suggested using a Python 3.2 subprocess backport available at http://code.google.com/p/python-subprocess32/ instead of hacking around the Python installation.
This let me install the module into my virtual environment's site-packages, and patch the subprocess code with http://hg.python.org/cpython/rev/767420808a62 to fix the bug mentioned in question. Afterwards, a simple import subprocess32 as subprocess fixed the problem.
You may know the Windows compliance tool that helps people to know if their code is supported by any version of the MS OS.
I am looking something similar for Python.
I am writing a lib with Python 2.6 and I realized that it was not compatible with Python 2.5 due to the use of the with keyword.
I would like to know if there is a simple and automatic way to avoid this situation in the future.
I am also interested in something similar to know which OS are supported.
Thanks for your help
In response to a previous question about this, I wrote pyqver. If you have any improvements, please feel free to fork and contribute!
I recommend you rather use automated tests than a code analysis tool.
Be aware that there are subtle behaviour changes in the Python standard library that your code may or may not depend upon. For example httplib: When uploading files, it is normal to give the data as a str. In Python 2.6 you can give stream objects instead (useful for >1GB files) if you nudge them correctly, but in Python 2.5 you will get an error.
A comprehensive set of unit tests and integration tests will be much more reliable because they test that your program actually works on Python version X.Y.
$ python2.6 tests/run_all.py
.................................
33 tests passed
[OK]
You're Python 2.6 compatible.
$ python2.4 tests/run_all.py
...........EEE.........EEE.......
27 tests passed, 6 errors
[FAIL]
You're not Python 2.4 compatible.
Python 2.5 can still be saved, since it can use the with keyword:
from __future__ import with_statement