PrettyTable 0.5 Release Candidate 1 available for download

[Luke Maurits]

Greetings list,

Following the release of PrettyTable 0.4, I have received a few bug
reports, a few bug fixes and some new features. After incroporating
the submitted work and fixing reported bugs, I have called the result
PrettyTable 0.5 Release Candidate 1. No extra features of any kind
will be added to this version before it is released as PrettyTable
0.5, but bug fixes *will* be made before that happens.

I would appreciate interested users dowloading 0.5 RC1 and plugging it
into their existing PrettyTable applications to see if anything
breaks. You can report bugs (or even complete successes!) to this
list. If significant bugs turn up, then the version with those fixed
will become RC2, and so on. Once a few days have passed with nobody
reporting any new problems, the latest release candidate will become
0.5.

Things to notice or test in particular for 0.5 RC1:

* When printing with headers=False and border=False, there should no
longer be an extraneous newline near the top of the table.
* When printing with headers=False, column widths will be reduced as
appropriate in columns where the field name is wider than the data.
* I think Unicode support is better. Those of you who have had
problems getting accented characters to print properly in headers
should check to see if your problem has been solved in RC1.
* The border=True / border=False setting now actually does something
in the print_html / get_html_string methods.
* The print_html and get_html_string methods now accept an attributes
argument which is a dictionary of name/value pairs to be placed inside
the <table> tag (so you can, e.g. set class, name or id values in
order to work with CSS).
* The print_html and get_html_string methods now, by default, do their
best to match the various formatting options in their HTML output.
They use inline CSS to adjust the alignment of data in columns, the
padding widths of columns and in some cases the border settings. You
can give either method a format=False attribute to turn this behaviour
off if you want to do your own styling. With format=False the methods
print a "bare bones" table, similar to the default behaviour in 0.4.

If you encounter any problems with any of these features (or indeed
any others), reply to this post, or email me at luke AT maurits DOT id
DOT au and I'll make sure they are cleared up before 0.5 is released.

Thanks in advance for your testing efforts,
Luke

[Chris Clark]

On May 19, 3:10 am, Luke Maurits <l...@maurits.id.au> wrote:
>.....After incroporating

> the submitted work and fixing reported bugs, I have called the result
> PrettyTable 0.5 Release Candidate 1.  No extra features of any kind
> will be added to this version before it is released as PrettyTable
> 0.5, but bug fixes *will* be made before that happens.

Thanks for the new release. The new "format" stuff seems to break
borders:

from prettytable import PrettyTable
num_cols=3
header = [str(x) for x in range(num_cols)]
pt = PrettyTable(header, padding_width=0, left_padding=1)
tmp_row= [str(x) for x in range(num_cols)]
pt.add_row(tmp_row)
str_table = pt.get_html_string(format=False, border=False, attributes=
{'id': 'stripedtable'})
print str_table

I.e. borders always get generated (even if border=False) if
format=False, if format=True they are not generated.

As a side note the performance seems slower, I've not even timed it
with a wall clock yet alone tried using profiling, etc. so this could
all be in my head :-)

Chris

[Chris Clark]

Chris Clark wrote:
> The new "format" stuff seems to break
> borders:
>

See attached patch (I've inlined it to as I can't remember what google
groups does to attachments.

I deliberately forced the params _get_simple_html_string() of match
_get_formatted_html_string() (whether those params are used or not) for
consistency.

Chris

--- prettytable-0.5-RC1.py Thu May 21 10:30:33 2009
+++ prettytable.py Thu May 21 17:08:24 2009
@@ -456,21 +456,23 @@
return self.html_cache[key]

if format:
- string = self._get_formatted_html_string(start, end,
fields, sortby, reversesort, header, border, hrules, attributes)
+ tmp_html_func=self._get_formatted_html_string
else:
- string = self._get_simple_html_string(start, end, fields,
sortby, reversesort, attributes)
+ tmp_html_func=self._get_simple_html_string
+ string = tmp_html_func(start, end, fields, sortby, reversesort,
header, border, hrules, attributes)

if self.caching:
self.html_cache[key] = string

return string

- def _get_simple_html_string(self, start, end, fields, sortby,
reversesort, attributes):
+ def _get_simple_html_string(self, start, end, fields, sortby,
reversesort, header, border, hrules, attributes):

bits = []
# Slow but works
table_tag = '<table'
- table_tag += ' border="1"'
+ if border:
+ table_tag += ' border="1"'
if attributes:
for attr_name in attributes:
table_tag += ' %s="%s"' % (attr_name,
attributes[attr_name])

[Luke Maurits]

Thanks for the patch, Chris, I've applied it to my local copy.

It's been a week now since I made the announcement that started this
thread. It seems like nobody else is going to report anything so I
think that either later today or tomorrow I will release 0.5 RC1 +
your patch as 0.5.

This will be a fairly significant turning point, not just because of a
new release. Once 0.5 is out I'm going to import it into the
project's svn repository so project members will be able to contribute
code that way soon. I also plan for 0.6 to be quite an important
release - no new features will appear in it but the API will be tidied
up considerably in the direction of simplicity, uniformity and
Pythonicness. After 0.6 I will endeavour to maintain backwards
compatibility of the API as much as possible, so it will be important
that 0.6 is done well. Interested users should keep an eye on the
devel list as I'll be throwing out ideas and soliciting opinions for
0.6 shortly after the release of 0.5.

Luke