[reportlab-users] Ammendment: Allow Blank Cells in Platypus Table plus None Comparison Check

[Andy Robinson]

Benn wrote:
> Hey All,
> 
> Sorry about the duplicate post previous to this.
> 
> I did a bit more of my homework and put together a proper test case, in the
> process (naturally) identifying a few discrepancies.
> 
> The Table() now accepts as data any mixture of lists or tuples (as well as,
> presumably, other iteratable data), proper handling of None, and support for
> partially filled in rows throughout the datasource.
> 


For separate but coincidental reasons, I had to check something in just 
now on the trunk to handle unicode strings in table cells.

str(u'Hello') is fine, but if you have non-ascii input then it blew up. 
  A new method in Table is called once which does what one might call
     normalizeData(self, matrix) -> newMatrix

I made it do None -> '' as well as unicode -> utf8,  but did not do 
str() on everything else, as we accept lists/tuples of flowables as 
allowed 'cell values', and possibly some other weird stuff when tables 
split over pages.  I'll get a colleague to look at your patch in the 
morning and see if it's safe in this respect or needs some tweaks.  (And 
thanks for the test case updates!)

The feature I am not sure about is whether to right-pad rows which are 
too short.  This might indicate faulty data or algorithms the user might 
want to know about, and can easily be accomplished by a library function 
users call if/whn needed.  If your data comes from an SQL database, the 
cells are usually all there; on the other hand is you parsed a CSV or 
Excel sheet, you might well have missing rightmost cells.

What do people think?  Should tables accept occasional 'short rows' and 
pad to the right with empty cells, or be strict about demanding 
rectangular input of the correct number of columns?

- Andy