[reportlab-users] Ammendment: Allow Blank Cells in Platypus
Table plus None Comparison Check
rl at magitech.org
Thu May 4 21:54:01 EDT 2006
> 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:
if val is None:
if isinstance(val, unicode):
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
More information about the reportlab-users