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

[Benn]

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

Unicode strings are, imho, a nightmare in Python.  Why they didn't make them
either a subclass of str or just made all str object unicode I'll never
know... but anyways.

> str(u'Hello') is fine, but if you have non-ascii input then it blew up.

Why would you want to do such a thing, actually?  Admittedly, the strnone()
method would need a slight modification to not stomp over unicode strings,
probably something like:
def _strnone(val):
   if val is None:
      return ''
   if isinstance(val, unicode):
      return val
   return str(val)

Of course if something later on doesn't support unicode...

>   A new method in Table is called once which does what one might call
>      normalizeData(self, matrix) -> newMatrix

This is actually exactly what my main snippet did.  I thought about extracting
it into a function, but couldn't be bothered for something only used in one
place :)  But if it was possible to move the logic somewhere else so that it
wasn't a semi-wasted iteration through potentially large sums of data, then
that might be a good idea.

> 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!)

For the _strnone() method, all the places it gets called (just checked) are
already brackeded by the necessary if t in _SeqTypes or isinstance(v,Flowable)
checks, hopefully that's sufficient.

> 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.

I agree with part of this.  Is it RL's position to tell the user their data is
wrong?  I don't really think so -- if you pass in a partially populated grid
(as I did) then as long as the behavior is predictable and documented, it
should remain the programmers obligation to validate.  I wonder, though, if a
better solution might be instead of normalizing the matrix simply ignoring the
absence of columns -- essentially, for c in range(len(data[row]): ... instead
of explicitly looking for a column.  I don't know how well that would fit in
with the rest of the logic, though :)

> 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?

You know where I stand :P

Cheers,
--B