Skip to content

plotting/_compat Version Comparisons Not Working in Py27 #18633

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
WillAyd opened this issue Dec 4, 2017 · 1 comment · Fixed by #18637
Closed

plotting/_compat Version Comparisons Not Working in Py27 #18633

WillAyd opened this issue Dec 4, 2017 · 1 comment · Fixed by #18637
Labels
Compat pandas objects compatability with Numpy or Python functions
Milestone

Comments

@WillAyd
Copy link
Member

WillAyd commented Dec 4, 2017

I noticed this while setting up a virtual environment using matplotlib 1.4.0 to test #18190. __version__ sometimes returns a string and other times returns a unicode object in Python 2.7. When returning unicode, the comparisons that occur in plotting/_compat.py will raise

>>> from distutils.version import LooseVersion
>>> import matplotlib
>>> matplotlib.__version__
u'1.4.0'
>>> matplotlib.__version__ < LooseVersion("1.5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~/miniconda3/envs/mpl1_4/lib/python2.7/distutils/version.py", line 296, in __cmp__
    return cmp(self.version, other.version)
AttributeError: 'unicode' object has no attribute 'version'

In some cases, the versions are converted to str objects in plotting/_compat.py to presumably avoid this error, but it is not done consistently. As perhaps a better approach, we could create LooseVersion objects from all the __version__ properties so that the comparison is done between equal types across the board.

>>> LooseVersion(matplotlib.__version__) < LooseVersion("1.5")
True

Output of pd.show_versions()

Python 2.7.14 | packaged by conda-forge | (default, Nov 4 2017, 10:22:41)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import pandas as pd
pd.show_versions()

INSTALLED VERSIONS

commit: 2c903d5
python: 2.7.14.final.0
python-bits: 64
OS: Darwin
OS-release: 17.2.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: None.None

pandas: 0.22.0.dev0+283.g2c903d594.dirty
pytest: 3.3.0
pip: 9.0.1
setuptools: 38.2.3
Cython: 0.27.3
numpy: 1.9.3
scipy: None
pyarrow: None
xarray: None
IPython: None
sphinx: None
patsy: None
dateutil: 2.6.1
pytz: 2017.3
blosc: None
bottleneck: None
tables: None
numexpr: None
feather: None
matplotlib: 1.4.0
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
sqlalchemy: None
pymysql: None
psycopg2: None
jinja2: None
s3fs: None
fastparquet: None
pandas_gbq: None
pandas_datareader: None

@TomAugspurger
Copy link
Contributor

I've seen this error when a library imports unicode_literals.

As perhaps a better approach, we could create LooseVersion objects from all the version properties so that the comparison is done between equal types across the board.

That's probably best anyway.

@jreback jreback added the Compat pandas objects compatability with Numpy or Python functions label Dec 5, 2017
@jreback jreback added this to the 0.22.0 milestone Dec 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Compat pandas objects compatability with Numpy or Python functions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants