PrettyTable 0.6 Release Candidate 1 available for download

[Luke Maurits]

Hi prettytable-devel,

Tonight I've branched 0.6 off of trunk and tagged 0.6-RC01, the first
release candidate for 0.6. You can download a copy from the
"Downloads" tab of the Google code project homepage.

Bug reports and feedback from people on this list who kindly volunteer
to test RC01 will be used to make sure the eventual 0.6 release will
be as good as it can be, so if you are able please make time in the
coming days to give RC01 a whirl.

Translating your existing 0.5 applications to 0.6 will be trickier and
more error prone than previous version changes, on account of many
changes to the API. I apologise for the inconvenience this causes but
I hope everyone will agree that 0.6 is much easier to learn and use
and results in cleaner application code. Future releases will not
make any drastic changes from the 0.6 API so you should only have to
endure this difficult transition one time! Your patience is
appreciated.

The Wiki page at http://code.google.com/p/prettytable/wiki/Tutorial06
is a tutorial for the 0.6 API which you may like to read through
quickly before you try to convert your existing applications so you
know what to expect. If you find any problems with the Wiki page - if
the page says something should act one way but it acts differently, or
you feel like something should be better explained, or you just find a
spelling or grammar mistake - then please use the "Enter a comment"
box at the bottom of the page to let me know about it.

Thanks very much in advance to anybody who makes the time to give 0.6-
RC01 a try. I hope you enjoy the changes!

Luke

[Chris Clark]

Luke Maurits wrote:
> Translating your existing 0.5 applications to 0.6 will be trickier and
> more error prone than previous version changes, on account of many
> changes to the API. I apologise for the inconvenience this causes but
> I hope everyone will agree that 0.6 is much easier to learn and use
> and results in cleaner application code. Future releases will not
> make any drastic changes from the 0.6 API so you should only have to
> endure this difficult transition one time! Your patience is
> appreciated.
>

I just tried out trunk with a couple of my scripts. My html generator
(was using 0.5) works with 0.6/trunk without any code changes! Nice :-)

I had an old "generate a codepage chart" (like an ASCII chart but with
characters/bytes above 127 displayed) that didn't work but that was due
to the Unicode-support change I made a few releases back (rather than
version 0.6 related). I've attached a proposed patch (probably needs
some work as PrettyTable accepts kwargs rather than explicit regular
keyword arguments) that address this. This patch may also be the
building blocks of Python 3.0 compatibility (I don't use Python 3.x so
this is untested with 3.x). The patch basically preserves the Unicode
behavior but allows the caller to specify byte (or in Python 2.5 and
earlier, "str") semantics. Python 3.0 uses would need to call with str
so that 3.0 strings behavior works correctly.

Chris

[Luke Maurits]

Hi Chris,

Thanks for giving 0.6 a whirl, and sorry for my delayed response.

> I just tried out trunk with a couple of my scripts. My html generator
> (was using 0.5) works with 0.6/trunk without any code changes! Nice :-)

Even I'm pleasantly surprised to hear that! I guess this is good
confirmation that the heavily changed argument handling in 0.6 is
compatible with the old 0.5 system in those ways that it can be.

> I had an old "generate a codepage chart" (like an ASCII chart but with
> characters/bytes above 127 displayed) that didn't work but that was due
> to the Unicode-support change I made a few releases back (rather than
> version 0.6 related).

Ah, I remember that application. Thanks for the patch. I'm a little
busy at the moment with another project and with my thesis so I'm
tossing up between putting of 0.6 a little longer and waiting until I
have time to properly integrate your patch, or to declare that the
unicode/str issue is sufficiently minor that we can just release 0.6
as it is now and save the patch for 0.7. This would be an easier
decision to make if I was more knowledgeable about unicode in Python.
Am I correct in thinking that applications where the current behaviour
is a problem (like your ASCII chart) are unusual edge cases, and that
most people would want PrettyTable to print "high bytes" as proper
unicode characters if possible rather than whatever odd symbols you
want in your ASCII chart?

> This patch may also be the
> building blocks of Python 3.0 compatibility (I don't use Python 3.x so
> this is untested with 3.x).

I have actually given some thought to 3.x compatibility and your patch
is definitely a step in that direction. However, I don't think it's
ever going to be possible to have the one version of PrettyTable work
correctly on both 2.6.x and 3.x simply on account of the print -->
print() change. Hopefully by the time 3.x is in widespread usage
PrettyTable will be sufficiently complete and debugged that it won't
be a big deal to simply run it through 2to3 and bump up the major
release number and leave it at that.

Thanks again for your input,

Luke

[Chris Clark]

Luke Maurits wrote:

I had an old "generate a codepage chart" (like an ASCII chart but with
characters/bytes above 127 displayed) that didn't work but that was due
to the Unicode-support change I made a few releases back (rather than
version 0.6 related).
    

Ah, I remember that application.  Thanks for the patch.  I'm a little
busy at the moment with another project and with my thesis so I'm
tossing up between putting of 0.6 a little longer and waiting until I
have time to properly integrate your patch, or to declare that the
unicode/str issue is sufficiently minor that we can just release 0.6
as it is now and save the patch for 0.7.  This would be an easier
decision to make if I was more knowledgeable about unicode in Python.
Am I correct in thinking that applications where the current behaviour
is a problem (like your ASCII chart) are unusual edge cases, and that
most people would want PrettyTable to print "high bytes" as proper
unicode characters if possible rather than whatever odd symbols you
want in your ASCII chart?
  

As with most things, it depends :-) ...... But to try and give a real answer for a way forward, yes that seems a fair assessment if most of the user base is on Linux (where utf-8 is the norm). Most python devs I deal with are Linux or Mac users (I'm sort of the odd one out, I use a Windows desktop at work a lot).

This patch may also be the
building blocks of Python 3.0 compatibility (I don't use Python 3.x so
this is untested with 3.x).
    

I have actually given some thought to 3.x compatibility and your patch
is definitely a step in that direction.  However, I don't think it's
ever going to be possible to have the one version of PrettyTable work
correctly on both 2.6.x and 3.x simply on account of the print -->
print() change.  Hopefully by the time 3.x is in widespread usage
PrettyTable will be sufficiently complete and debugged that it won't
be a big deal to simply run it through 2to3 and bump up the major
release number and leave it at that.
  

There is a solution to that, or rather at least 2:

1. stop using print! :-) Instead do file IO. e.g. fileptr.write(). Not that I'm planning on moving to Py3 soon but my scripts (with PrettyTable) could move fairly easily as I call the "get table" routines rather than calling the "print table" routines.
2. If you like using print, switch to using a print-like function that has the same API as Py3 print(), e.g. "myprint", then you can either assign myprint=print in Py3 and later, for older releases the myprint func will simply make calls to the print statement
   

I'd suggest #1 - #2 could be achieved with the 2to3 scripts though.

You could combine #1 and #2 by using 2to3 scripts and then replacing all calls to print() to a file IO function.

The official recommendation from Python.org is keep to versions in parallel, but for small scripts/libs I think it is possible to keep the same code base.

Chris

[Luke Maurits]

On Tue, 09 Jun 2009 11:19:58 -0700

> There is a solution to that, or rather at least 2:
>

> 1. stop using print! :-)

I've been thinking about this and although it still feels kind of radical to do away with them, I've come to realise that the PrettyTable.printt() and PrettyTable.print_html() methods are in fact completely unecessary! Any call "x.printt(*args, **kwargs)" could be replaced by "print x.get_string(*args, **kwargs)" without any difference in result whatsoever. Eliminating the printing methods would (1) shorten the length of the module which is always a plus for maintenance, (2) solve any Python 3.x compatibility problems related to the print -> print() change (which would certainly be the biggest problem). If I included your patch and made this change the result would probably run just fine on 3.x.

This change would break a lot of existing code (I imagine), and since the idea has always been that 0.6 would be the release of big, breakey changes and after that the API would stabilise, it's more or less now or never for this idea. What do people think? If nobody has any compelling objections, I might do just this and put the result up as 0.6-RC2 for people to try out.

Luke