API: integrate with openpyxl 2.0-2.1 changes

[jtratner]

Builds are failing on Travis due to some issue with Excel (weirdly passed on merge but then started failing a few commits later). Currently investigating. C.f. https://travis-ci.org/pydata/pandas/jobs/35873580

@neirbowj - any idea why these tests stopped passing?

It's all some variation on the following:

======================================================================
ERROR: test_tsframe (pandas.io.tests.test_excel.OpenpyxlTests_NoMerge)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.4.1/lib/python3.4/site-packages/pandas/io/tests/test_excel.py", line 562, in test_tsframe
    df.to_excel(path, 'test1')
  File "/home/travis/virtualenv/python3.4.1/lib/python3.4/site-packages/pandas/util/decorators.py", line 88, in wrapper
    return func(*args, **kwargs)
  File "/home/travis/virtualenv/python3.4.1/lib/python3.4/site-packages/pandas/core/frame.py", line 1228, in to_excel
    startrow=startrow, startcol=startcol)
  File "/home/travis/virtualenv/python3.4.1/lib/python3.4/site-packages/pandas/io/excel.py", line 687, in write_cells
    'number_format':{'format_code': self.datetime_format}}))
  File "/home/travis/virtualenv/python3.4.1/lib/python3.4/site-packages/pandas/io/excel.py", line 757, in _convert_to_style_kwargs
    new_v = _conv_to_x(v)
  File "/home/travis/virtualenv/python3.4.1/lib/python3.4/site-packages/pandas/io/excel.py", line 1043, in _convert_to_number_format
    from openpyxl.styles import NumberFormat
ImportError: cannot import name 'NumberFormat'
----------------------------------------------------------------------

[jreback]

Ha, we just had this discussion!: #8340

apparently openpyxl released 2.0.5 (today 9/21). and made backward incompatible changes (no suprise their). The 3.4 build tests with the latest so picked it up.

So whatever fix is needed, prob should change say the 3.3 build to use the last good version as well (2.04?), though 2.6 build uses 2.03 (to make sure that WE maintain compat).

[jtratner]

it looks like a really minor change - maybe for now just switch the import
to openpyxl.styles.number.NumberFormat?

On Sun, Sep 21, 2014 at 12:43 PM, jreback notifications@github.com wrote:

Ha, we just had this discussion!: #8340
#8340

apparently openpyxl released 2.0.5 (today 9/21). and made backward
incompatible changes (no suprise their). The 3.4 build tests with the
latest so picked it up.

So whatever fix is needed, prob should change say the 3.3 build to use the
last good version as well (2.04?), though 2.6 build uses 2.03 (to make sure
that WE maintain compat).

—
Reply to this email directly or view it on GitHub
#8342 (comment).

[jreback]

@jtratner prob, just need to do it in a try: except: because have to keep the existing one around. Its really annoying when people change the API's around like that

[jreback]

hmm, might be something else as 2.0.5 seems to have been working for last few days (though its possible that what was called 2.0.5 changed), which is a no-no, but its possible

[jorisvandenbossche]

It is version 2.1.0 that is released, not 2.0.5 I think: http://openpyxl.readthedocs.org/en/latest/changes.html

[jtratner]

I just pushed a potential fix. If it works, let's just stick with the minor
changes rather than contorting ourselves to make things work with openpyxl
v2. good thing you said to mark it as experimental :)

On Sun, Sep 21, 2014 at 1:12 PM, Joris Van den Bossche <
notifications@github.com> wrote:

It is version 2.1.0 that is released, not 2.0.5 I think.

—
Reply to this email directly or view it on GitHub
#8342 (comment).

[jreback]

@jorisvandenbossche right

[neirbowj]

Grr. The OpenPyxl devs are making me regret getting roped into this.

It's not clear that using the deprecated NumberFormat class is a viable approach. It's been deprecated pretty emphatically:

>>> from openpyxl.styles import Style
>>> from openpyxl.styles.numbers import NumberFormat
>>> nf = NumberFormat(format_code='0.00')
openpyxl.styles.numbers:1: UserWarning: Call to deprecated function or class NumberFormat (Number formats are strings. Use module functions).
>>> s = Style(number_format=nf)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "openpyxl/styles/__init__.py", line 45, in __init__
    self.number_format = number_format
  File "openpyxl/styles/hashable.py", line 54, in __setattr__
    return object.__setattr__(self, *args, **kwargs)
  File "openpyxl/styles/numbers.py", line 194, in __set__
    super(NumberFormatDescriptor, self).__set__(instance, value)
  File "openpyxl/descriptors/__init__.py", line 32, in __set__
    raise TypeError('expected ' + str(self.expected_type))
TypeError: expected <type 'basestring'>

It looks like the main alternatives for us are to A) build in separate compatibility for the two flavors of number formats, or B) declare 2.x.y prior to 2.1.0 unsupported, and treat "number_format is a string" as the one true interface. Either way, it seems like this kind of breakage is going to be a fact of life with OpenPyxl going forward.

Thoughts?

[jreback]

can u ping their mailing list / issues
and see what the heck is up with all if these API changes

if they come back with - this is the API and it's stable - then if u can fix up
we can just make 2.1 min for 2.x series

otherwise maybe just revert and wait for stability

[neirbowj]

Yeah, I'll see what I can find out.

[neirbowj]

I've opened the hailing frequencies.