Favoring A Pip-installed Module Over The Standard Library Copy
Solution 1:
I can't help with the previously installed argparse
versions, but may be able to make few helpful observations.
ipython
is a heavy user of argparse
, though in its own way. It builds a parser from the config
files, and uses that to process your commandline. So your commandline has a last minute chance to override many comfig options.
And %magic
commands are parsed with a version of argparse
.
Development of the PyPi version ceased once it became standard (Python 2.7). Version number in the standard is meaningless. It is still (in the latest Python 3.5).
In [4]: argparse.__version__
Out[4]: '1.1'
I don't know how it can be done, but any module that seeks to install argparse
should first check the Python version. If it 2.7 or newer, it should use the standard argparse
.
Keep in mind that the argparse module is one self contained file, argparse.py
. In my experience ipython
works fine with a copy of that file in my own current working directory. I do that all the time when testing patches for argparse bug/issues.
Other than 2.6 compatibility, I can't think of a reason why a package would want a PyPi version of argparse instead of the standard one. Does any of the discussions indicate what kinds of incompatibilities might arise?
According the current PyPi version (1.4) NEWS.txt
, the repository is now
https://github.com/ThomasWaldmann/argparse
It may be work exploring there to see what compatibility issues there are between than and the standard version(s).
Both the PyPi version and the standard library have test_argparse.py
unittest files. They could be used to test for compatibilities.
Post a Comment for "Favoring A Pip-installed Module Over The Standard Library Copy"