255 column limit workaround?

[schmichael]

xlwt/Row.py:73 imposes a 255 column limit on worksheets. Is there any
way around this limit or is it a hard limit in Excel?

Thanks to the developers for a great tool!

Michael Schurter

PS - For future searhability, the exception you'll see if you hit
this limit is: ValueError("column index (%r) not an int in range(256)"
% arg)

[John Machin]

schmichael wrote:

Welcome to the group!

> xlwt/Row.py:73 imposes a 255 column limit on worksheets.

No it doesn't. It's a check against an *existing* limit of *256*, not
255. I put it in so that the erring caller gets a controlled immediate
exception with a precise meaningful message -- otherwise it will blow up
much later (at the Workbook.save() stage) with a not-very-helpful message.

> Is there any
> way around this limit or is it a hard limit in Excel?

65,536 rows (16,384 in earlier versions) and 256 columns are hard limits
in Excel's .xls file format, the default "save as" format up to Excel 11
aka Excel 2003. Excel 12 aka Excel 2007 introduced .xlsx (XML) and .xlsb
(binary) which support up to 1,048,576 rows by 16,384 columns; so far
there have been exactly 0 expressions of interest in either of those
formats being supported by xlwt.

> Thanks to the developers for a great tool!

I'll say thanks for the compliment on behalf of Roman Kiseliov, the
developer of pyExcelerator (of which xlwt is a fork) -- anyone else can
be described only as "sporadic maintainer" :-)

Cheers,
John

[michael schurter]

On Mon, Jul 14, 2008 at 11:34 AM, schmichael <michael....@gmail.com> wrote:
>
> xlwt/Row.py:73 imposes a 255 column limit on worksheets. Is there any
> way around this limit or is it a hard limit in Excel?

After some testing it seems as though this is a hard limit in Excel
until Excel 2007.

[michael schurter]

On Mon, Jul 14, 2008 at 5:38 PM, John Machin <sjma...@lexicon.net> wrote:
> Welcome to the group!

Thanks!

>> xlwt/Row.py:73 imposes a 255 column limit on worksheets.
>
> No it doesn't. It's a check against an *existing* limit of *256*, not
> 255. I put it in so that the erring caller gets a controlled immediate
> exception with a precise meaningful message -- otherwise it will blow up
> much later (at the Workbook.save() stage) with a not-very-helpful message.

I actually monkeypatched Row.py to bypass the check and it let me save
just fine. However, OpenOffice complains the file is broken and only
displays 256 columns, and I'm sure Excel would do the same. So the
check is very helpful. Thanks! :)