Code compatibility broken: set_field_names not found

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install current prettytable
2. Run the following in a Python shell:
>>> import prettytable
>>> pt = prettytable.PrettyTable()
>>> pt.set_field_names
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/prettytable.py", line 163, in __getattr__
    raise AttributeError(name)
AttributeError: set_field_names

What is the expected output? What do you see instead?

This works in prettytable 0.5

Original issue reported on code.google.com by kirillmu...@gmail.com on 21 Nov 2012 at 2:06

[GoogleCodeExporter]

I have the same exact problem. The method set_field_names is not present in 
version 6:

print(dir(pt))

['__class__', '__delattr__', '__dict__', '__doc__', '__format__', 
'__getattr__', '__getattribute__', '__getitem__', '__hash__', '__init__', 
'__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', 
'__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__unicode__', 
'__weakref__', '_align', '_attributes', '_border', '_compute_widths', '_end', 
'_field_names', '_fields', '_float_format', '_format', '_format_value', 
'_get_align', '_get_attributes', '_get_border', '_get_end', '_get_field_names', 
'_get_float_format', '_get_format', '_get_formatted_html_string', 
'_get_header', '_get_horizontal_char', '_get_hrules', '_get_int_format', 
'_get_junction_char', '_get_left_padding_width', '_get_max_width', 
'_get_options', '_get_padding_width', '_get_padding_widths', 
'_get_reversesort', '_get_right_padding_width', '_get_rows', 
'_get_simple_html_string', '_get_sort_key', '_get_sortby', '_get_start', 
'_get_vertical_char', '_header', '_horizontal_char', '_hrules', '_int_format', 
'_junction_char', '_left_padding_width', '_max_width', '_options', 
'_padding_width', '_reversesort', '_right_padding_width', '_rows', 
'_set_align', '_set_attributes', '_set_border', '_set_columns_style', 
'_set_default_style', '_set_end', '_set_field_names', '_set_float_format', 
'_set_format', '_set_header', '_set_horizontal_char', '_set_hrules', 
'_set_int_format', '_set_junction_char', '_set_left_padding_width', 
'_set_max_width', '_set_msword_style', '_set_padding_width', 
'_set_random_style', '_set_reversesort', '_set_right_padding_width', 
'_set_sort_key', '_set_sortby', '_set_start', '_set_vertical_char', 
'_sort_key', '_sortby', '_start', '_stringify_header', '_stringify_hrule', 
'_stringify_row', '_validate_align', '_validate_all_field_names', 
'_validate_attributes', '_validate_field_name', '_validate_float_format', 
'_validate_function', '_validate_hrules', '_validate_int_format', 
'_validate_nonnegative_int', '_validate_option', '_validate_single_char', 
'_validate_true_or_false', '_vertical_char', '_widths', 'add_column', 
'add_row', 'align', 'attributes', 'border', 'clear', 'clear_rows', 'copy', 
'del_row', 'encoding', 'end', 'field_names', 'float_format', 'format', 
'get_html_string', 'get_string', 'header', 'horizontal_char', 'hrules', 
'int_format', 'junction_char', 'left_padding_width', 'max_width', 
'padding_width', 'reversesort', 'right_padding_width', 'set_style', 'sort_key', 
'sortby', 'start', 'vertical_char']

_set_field_names is present, though.

Original comment by paulhtre...@gmail.com on 20 Jan 2013 at 11:11

[GoogleCodeExporter]

As of PrettyTable 0.6, the set_field_names() method no longer exists.  0.6 was 
a deliberately compatibility-breaking release to improve the API.  However, I 
kind of dropped the ball on thoroughly documenting the changes and the Wiki 
sometimes includes example code using the old style.  So this is really a 
documentation bug, not a code bug.

To set field names in 0.6 and beyond, use the following syntax:

pt.field_names = ["Foo", "Bar", "Baz"]

If this doesn't work, then *that* is a code bug - please let me know.

Original comment by luke@maurits.id.au on 21 Jan 2013 at 9:06

• Changed state: Invalid

[GoogleCodeExporter]

I understand your decision. However, this makes prettytable particularly 
difficult to use in our environment, as we cannot be sure which version of 
prettytable is installed. In particular, prettytable is in 0.5 in Debian 
squeeze and is likely to stay that forever [1]. On the other hand, it is rather 
current in the most recent Ubuntu LTS [2].

What do you suggest? It might be after all that compatibility methods that 
first issue a warning (0.6), then an error unless it is explicitly enabled 
(0.7) and only after that are removed (0.8 or 1.0) would have been a safer bet.

[1] http://packages.debian.org/squeeze/python-prettytable
[2] https://launchpad.net/ubuntu/+source/prettytable

Original comment by kirillmu...@gmail.com on 21 Jan 2013 at 9:34

[GoogleCodeExporter]

Ah.  I understand the difficult situation you are in, writing code that you 
would like to work out of the box on Debian and Ubuntu.  I apologise that the 
abrupt change in API has put you in this situation.  I think that at the time 
(and probably still even now) I drastically underestimated how widely 
PrettyTable was deployed.

The gradual transition probably would have been best, although I do not know 
what I can do now to fix it, since Squeeze will never see it's PrettyTable 
package updated.  It looks like Wheezy has 0.6 in it, so hopefully things will 
become easier when Wheezy becomes stable (which hopefully is not too far off), 
although I am sure that is of little consolation to you now.

One option of course would be to subclass PrettyTable and in your custom class 
write a set_field_names method which uses the value of prettytable.__version__ 
to test if you are at 0.5 or 0.6 (effectively, Debian or Ubuntu) and then do 
the appropriate thing.  This is a little ugly, but at least it should let you 
use the same code on both platforms.

Alternatively, if this would work well in your environment, I could maybe set 
up an apt repository which hosted the latest version of PrettyTable packaged up 
for Debian stable.  You could add that to your apt sources list and that way 
get 0.6 on Debian.  But I understand that you may be in an environment where 
that kind of change is not easy/acceptable.  Let me know if you are interested 
and I will look into this option - I've never hosted an apt repo before, or 
even packaged up a .deb, so I can't guarantee quick turn around time, but I 
will give it my best to make up for this situation.

In future, I will be more careful about compatibility breaks!

Original comment by luke@maurits.id.au on 21 Jan 2013 at 10:01

[GoogleCodeExporter]

Thank you for your fast reply. Perhaps the easiest thing for our project would 
be to include a static copy of prettytable, so please don't bother setting up 
an apt repo. Still, you could add compatibility methods to the current version 
of prettytable *if* this is an easy thing to test, perhaps with a "deprecated" 
decorator [1]? I'm not sure if that would reach current LTS, though.

[1] http://code.activestate.com/recipes/577819-deprecated-decorator/

Original comment by kirillmu...@gmail.com on 22 Jan 2013 at 12:00

[GoogleCodeExporter]

Alright, I won't worry about the apt repo.  I hope the static copy solution 
works well for you.

Regarding the deprecated decorator...well, first off, I will definitely use 
that kind of stuff for future syntax changes (although hopefully they will be 
rare, the idea was for 0.6 to be "one big compatibility breaking release" to 
get things looking their best and then for syntax to never change).

As for addressing this particular problem...well, I have just spoken to the guy 
who packages pt for the official Debian repositories, and it is basically too 
late for anything I release now to make it into Wheezy without a lot of 
trouble, and I don't want to trouble the volunteer packager by insisting he 
push anything through.  So even if I added a deprecation notice and released 
0.7 right this minute, nobody who uses Debian would see it for about two years. 
 Presumably by that time they will have changed their code anyway.  Also, by 
the time the Debian release after Wheezy comes out we'll hopefully be a few 
more versions of PrettyTable along.

I don't know what the policy is for Ubuntu's LTS, but like you said it may not 
reach that either, in which case it probably wouldn't end up doing anybody much 
good.

Original comment by luke@maurits.id.au on 22 Jan 2013 at 1:01